InfoMagic Standards 1994 January/InfoMagic Standards - January 1994.iso/ccitt/1988/troff/3_8_03.tro

Text File | 1991-12-12 | 123KB | 3,916 lines

.rs
.\" Troff code generated by TPS Convert from ITU Original Files
.\"                 Not Copyright ( c) 1991
.\"
.\" Assumes tbl, eqn, MS macros, and lots of luck.
.TA 1c 2c 3c 4c 5c 6c 7c 8c
.ds CH
.ds CF
.EQ
delim @@
.EN
.nr LL 40.5P
.nr ll 40.5P
.nr HM 3P
.nr FM 6P
.nr PO 4P
.nr PD 9p
.po 4P

.rs
\v | 5i'
.sp 2P
.LP
\fBRecommendation\ I.333\fR
.RT
.sp 2P
.sp 1P
.ce 1000
\fBTERMINAL\ SELECTION\ IN\ ISDN\fR
.EF '%    Fascicle\ III.8\ \(em\ Rec.\ I.333''
.OF '''Fascicle\ III.8\ \(em\ Rec.\ I.333    %'
.ce 0
.sp 1P
.ce 1000
\fI(Melbourne, 1988)\fR
.sp 9p
.RT
.ce 0
.sp 1P
.LP
\fB1\fR     \fBIntroduction\fR
.sp 1P
.RT
.PP
This Recommendation defines \*Qterminal selection\*U as the procedures
carried out between a terminating ISDN exchange and ISDN terminal equipment
situated behind an ISDN interface leading to customer premises whereby
terminal response equivalent to answer or rejection is solicited. The procedures
apply to both point\(hyto\(hypoint and point\(hyto\(hymultipoint terminal
operations.
.PP
Note that in case of an existing terminal (TE2) connected via a
terminal adaptor (TA) to an ISDN access, the combination of TA and TE2
is seen as to provide the same functionality as a TE1. As there should
be no
modifications to the existing terminal, the functions described are provided
by the terminal adaptor.
.PP
\fINote\fR \ \(em\ In the context of this Recommendation \*Qterminal\*U is an
abstract term and does not constrain the implementation of physical terminals
which may consist of one or more logical terminals.
.RT
.sp 1P
.LP
1.1
    \fITerminal selection responsibilities\fR
.sp 9p
.RT
.PP
The network responsibility is to deliver a call to the interface
identified by the called number using connection types consistent with the
service requested by the calling party. It is the responsibility of the
called party to arrange the terminals on the interface so that incoming
calls properly originated are accepted only by the appropriate terminal(s).
The network may
provide additional functions to aid in the completion of calls from dedicated
networks. The network may provide additional services to ensure that calls
are completed only to terminals consistent with information provided by
the caller. It is the responsibility of the terminal manufacturer and/or
service provider to provide terminals that use the terminal selection data
in a way that is
consistent with the intended application of the terminal, (e.g.\ for telematic
terminals according to Recommendation\ T.90).
.PP
The calling party agrees, when placing a call, to accept the
terminating capabilities provided by the called party. The terminating
exchange has a cooperative role with the terminal in establishing an information
transfer which lends itself to the required terminal selection needs for a
given interface.
.RT
.sp 1P
.LP
1.2
    \fIIdentification requirements\fR
.sp 9p
.RT
.PP
An ISDN number identifies any of the interfaces at reference
point S (Recommendation\ I.330, \(sc\ 2.1). Additional identifiers or terminal
selection functions are therefore needed in those cases where the number is
insufficient to make needed distinctions among terminals. This Recommendation
addresses the general principles to be applied in identifying:
.RT
.LP
    1)
    specific individual terminals or
.LP
    2)
    groups of terminals among which no further distinction is
required by the terminating user.
.LP
     Specific sequences in which identifying information is applied are not
specified.
.sp 1P
.LP
1.3
    \fIGeneral operations\fR
.sp 9p
.RT
.PP
While specific selection sequences for the application of terminal identifiers
are not required, the ISDN number is a fundamental discriminator. The whole
network \(em\ including the terminating exchange\ \(em relies heavily on
this resource. The bearer capability must also be given a high status since
its
transfer across the interface is mandatory with every call request. Other
information potentially useful in the selection process is given in \(sc\ 4. An
originator of a call is generally not required to provide any of the other
information in every call. Exceptions for telematic terminals are listed in
Recommendation\ T.90.
.bp
.PP
If terminal selection is to be successful in establishing a connection
between the calling and the called terminal in a prescribed manner, the
calling terminal should conform to the reasonable expectations of the called
subscriber's terminal arrangement. A calling subscriber who does not conform
to the expectations of the called subscriber's terminal arrangement is
inviting an irregularity. The terminating subscriber has a corresponding
obligation to
provide a means for needed discrimination among terminals. It should be
noted that information expected at a called subscriber's terminal configuration
may not, in all cases, be provided by the calling subscriber, (for example,
interworking with a non\(hyISDN).
.PP
The point\(hyto\(hymultipoint operation tends to be emphasized in subsequent
text because distinctions in this mode of operation require some terminal
selection functions. Nevertheless, the treatment of both point\(hyto\(hypoint
and
point\(hyto\(hymultipoint selection procedures are considered appropriate
for this
Recommendation. The terminal selection stage is said to be completed when an
individual terminal reacts and is awarded the call. In the case of NT2, the
call award need not come as a direct result of the point\(hyto\(hypoint
procedure but may come later from a terminal attached to the NT2.
.PP
The details regarding the processing of this information by the
terminating exchange and the sequence used in offering this information
to the user\(hynetwork interface may be a matter of formal agreement between
the
subscriber and the Administration at the time of service provisioning.
The call set\(hyup and terminal selection procedures in ISDN require that
the terminating exchange and the terminals play cooperative roles.
.RT
.sp 2P
.LP
\fB2\fR     \fBObjective\fR
.sp 1P
.RT
.PP
2.1\fI\fR The primary objective of this Recommendation is to provide
overall principles on terminal selection in ISDN. This Recommendation therefore
provides a framework within which Administrations may choose appropriate
terminal selection procedures, to suit their own operating environment and
applications.
.sp 9p
.RT
.PP
2.2
The guidelines contained in the appendices do not represent
requirements on terminals for terminal selection functionality, but represent
terminal selection techniques that are useful in appropriate circumstances.
Possible choices are contained in appendices. However, other Recommendations,
e.g.\ Recommendation\ T.90 have also to be taken into account.
.sp 2P
.LP
\fB3\fR     \fBScope\fR
.sp 1P
.RT
.PP
3.1
It is recognized that call set\(hyup is an end\(hyto\(hyend process
requiring appropriate switching, signalling and terminal functionality
at both ends. However, the frame of reference used in this Recommendation
is mainly the terminating ISDN exchange and the terminal configuration(s)
served by that
exchange. The originating exchange and the terminal configuration(s) served
by that exchange are covered only if a specific request for a terminal
function at the calling side, supporting the terminal selection procedure
at the called
side, is identified.
.sp 9p
.RT
.PP
3.2
It is also recognized that calls originating from existing
dedicated networks with limited addressing and signalling capabilities
will not be able to avail themselves of the full range of terminal identification
functions. This Recommendation therefore addresses the terminal selection
for the following types of calls:
.LP
    \(em
    calls within the ISDN:
.LP
    i)
    selection based on network assisted capabilities
(e.g.\ see Appendices\ II and\ III);
.LP
    ii)
    selection based on end\(hyto\(hyend user capability
(e.g.\ see Appendices\ I and\ II);
.LP
    \(em
    calls from public dedicated networks to ISDN.
.PP
\fINote\fR \ \(em\ Calls from private networks to ISDN are not currently
addressed in this Recommendation.
.bp
.PP
3.3
This Recommendation addresses terminal selection in ISDN for
both basic and primary rate access.
.sp 9p
.RT
.PP
3.4
Though selection of a specific terminal in a multipoint
configuration in ISDN for maintenance and operation purposes may be a
requirement, this Recommendation does not currently address this application.
.PP
3.5
This Recommendation is related to and/or is compatible with the
following Recommendations:
.LP
    \(em
    Recommendations of the I.200\(hySeries on ISDN services;
.LP
    \(em
    Recommendation I.330: ISDN numbering and addressing
principles;
.LP
    \(em
    Recommendation I.331 (E.164): Numbering plan for the ISDN
era;
.LP
    \(em
    Recommendations I.410, I.411, I.412: ISDN user\(hynetwork
interfaces;
.LP
    \(em
     Recommendation I.441 (Q.921): ISDN user\(hynetwork interfaces: layer
2 specifications;
.LP
    \(em
     Recommendation I.451 (Q.931): ISDN user\(hynetwork interfaces: layer
3 specifications;
.LP
    \(em
    Recommendations of the I.500\(hySeries defining interworking
between various networks;
.LP
    \(em
    Recommendation Q.932, Annex A: Generic procedures for the
control of ISDN supplementary services \(em\ User service profiles and terminal
identification;
.LP
    \(em
    Recommendation T.90: Characteristics and protocols for
terminals for telematic services in ISDN.
.sp 2P
.LP
\fB4\fR     \fBTerminal selection functions\fR
.sp 1P
.RT
.PP
4.1
Any information which categorizes attributes of an incoming
call may be used for the terminal selection process (some information given
hereafter is service oriented and some is terminal oriented):
.sp 9p
.RT
.LP
    1)
    an ISDN number;
.LP
    2)
    bearer capability;
.LP
    3)
    other low layer functionality;
.LP
    4)
    higher layer functionality;
.LP
    5)
    direct dialling\(hyin (DDI) number, multiple subscriber number, or subaddress;
.LP
    6)
    ISDN/non\(hyISDN call source indicator;
.LP
    7)
    local exchange functionality.
.PP
In a point\(hyto\(hymultipoint configuration, call set\(hyup information
from the terminating ISDN exchange to the terminal configuration is transferred
via broadcast procedures. All active terminals receive attribute values
and
determine whether or not to respond.
.PP
In the case of more than one terminal supporting the same service, the
supplementary service Multiple Subscriber Number (MSN) (Note\ 1) or Direct
Dialling\(hyIn (DDI) (Note\ 2) may be used to identify a specific terminal. To
support these services the terminal must be able to recognize its own identity
based typically on a number of digits, which consist of the whole, or a
part of the Subscriber Number (SN) in the ISDN numbering plan. Alternatively,
\(sc\ 4.3 may apply.
.PP
This principle applies for both a homogeneous ISDN environment and for
interworking cases with non\(hyISDN. In a homogeneous ISDN environment
the
subaddressing function (Note\ 3) may be used alternatively. However, it
cannot be used in all cases of interworking.
.PP
\fINote\ 1\fR \ \(em\ Based on the use of distinct ISDN numbers, the multiple
subscriber number supplementary service enables specific terminal(s), connected
to the basic access in a point\(hyto\(hymultipoint configuration, to be
indicated by the called party number.
.PP
\fINote\ 2\fR \ \(em\ Based on the use of distinct ISDN numbers, the direct
dialling\(hyin supplementary service enables a user to establish a connection
to another user or an ISPBX, or other private system without attendant
intervention.
.PP
\fINote\ 3\fR \ \(em\ Based on an extension of the addressing capability
beyond the E.164 (I.331) numbering plan, subaddressing enables the calling
user to
select a specific terminal at the called user's termination and/or to invoke
a specific process in the called terminal at the called user's termination.
.bp
.RT
.PP
4.2\fR
The terminal selection function in \(sc 4.1 is currently supported by Recommendation\
Q.931 (I.451) call set\(hyup protocols, Q.932 and Q.921 as
follows:
.sp 9p
.RT
.LP
    1)
    called party number information element;
.LP
    2)
    bearer capability information element;
.LP
    3)
    low layer compatibility information element;
.LP
    4)
    High Layer Compatibility (HLC) information element;
.LP
    5)
    called party number/subaddress information element;
.LP
    6)
    progress indicator information element;
.LP
    7)
    End point Identifier (EID) information element (see Q.932, Annex\ A);
.LP
    8)
    Terminal End point Identifier (TEI) (see Q.921,
\(sc\ 3.3.4).
.PP
4.3
It is recognized that a local procedure, between the ISDN
exchange and terminal, may be provided to allow the exchange to assign a
particular terminal with network parameters (e.g.\ logical terminal profile).
This identification mechanism will assist the exchange in providing additional
terminal selection or service features (see Appendix\ III).
.sp 9p
.RT
.LP
\fB5\fR     \fBTerminal selection\fR
.sp 1P
.RT
.sp 2P
.LP
\fI\fR 5.1
    \fICalls within ISDN(s)\fR
.sp 1P
.RT
.sp 1P
.LP
5.1.1
    \fITerminal selection functions\fR
.sp 9p
.RT
.PP
These are described in \(sc 4.
.RT
.sp 1P
.LP
5.1.2
    \fIProcessing of selection functions\fR
.sp 9p
.RT
.PP
In the terminating exchange, the called subscriber number and the bearer
capability are checked. If any form of subscriber profile exists for the
interface, it may also be consulted.
.RT
.LP
    a)
    For point\(hyto\(hypoint applications
.LP
     Proceed to establish the connection according to subscriber requirements;
for an NT2 transfer all appropriate information.
.LP
    b)
    For point\(hyto\(hymultipoint applications (broadcast)
.LP
    i)
    As information is broadcast from the terminating
exchange to the terminal configuration, each active terminal receives the
presented information to identify the requested service, as described in
\(sc\ 4.1
.LP
    ii)
     Each active terminal which wishes to be awarded the call will inform
the network. The network will award the call to the first
terminal equipment which requests connection.
.LP
    When supporting multiple types of terminals, e.g.
telematic and telephone terminals, on a point\(hyto\(hymultipoint configuration,
improper call handling will occur if inappropriate terminals request connection
of the call. Appendices\ I, II and\ III provide possible solutions to these
problems. e.g.\ solutions specifically aimed at telematic terminals are
included in Appendix\ I.
.PP
The development of terminal configurations in addition to those
described in the appendices which will operate successfully in specific
circumstances (e.g.\ select a specific terminal from among several for
services, supplementary services, maintenance operations,\ etc.) are for
further study.
Provision of guidance to terminal manufacturers, ISDN subscribers, and
network operators about how terminals might respond in such circumstances,
requires
further study.
.sp 1P
.LP
5.1.3
    \fITerminal differentiation\fR
.sp 9p
.RT
.PP
The terminating party is expected to arrange available terminals to facilitate
access. Distinctions may be drawn, for example, by taking notice in a terminal
of the presence or absence (not the content) of a subaddress (see
also \(sc\ 4.2). Calls interworking from PSTN (bearer capability 3.1\ kHz
audio),
for example, could be accepted by terminals sensing no subaddress, while
allowing more capable terminals to bid for calls with the same bearer
capability and subaddress as well.
.bp
.RT
.sp 1P
.LP
5.2
    \fICalls from PSTN to ISDN\fR
.sp 9p
.RT
.PP
A call originated in the PSTN, supported by conventional signalling prior
to arrival at the ISDN interworking point, will belong to one of two
indistinguishable call types, i.e.\ ordinary speech or voiceband data. At the
interworking point the bearer capability \*Q3.1\ kHz audio\*U will be assigned
to
assure compatibility with these call types. A progress indicator is also
applied to mark a non\(hyISDN call source. Some PSTN customers, however,
will be served from ISDN\(hycapable exchanges and calls will be supported
by common
channel signalling for the entire connection. This affords some added
opportunities to make distinctions. The extent to which this should be
recommended is for further study.
.PP
Those cases where the bearer capability \*Q3.1 kHz audio\*U does not apply
(such as digital data service based on digital PSTNs) require further study,
based on Recommendation\ I.231, and Recommendation\ I.515.
.RT
.sp 1P
.LP
5.3
    \fICalls from PSPDN to ISDN\fR
.sp 9p
.RT
.PP
A call originated in the PSPDN will carry either a circuit or a
packet bearer capability when presented to an ISDN terminal (case\ A or\ B
according to Recommendation\ X.31). Terminal selection procedures in these
cases are for further study.
.RT
.sp 1P
.LP
5.4
    \fICalls from CSPDN to ISDN\fR
.sp 9p
.RT
.PP
A call originated in the CSPDN will carry a circuit bearer
capability and indicate the kind of bitrate adaption used when presented
to an ISDN terminal configuration. If the CSPDN is used to offer a teleservice,
e.g.\ Teletex in some countries, the interworking point may not be able to
provide this information to ISDN. Therefore, a distinction between a circuit
mode data call and a Teletex call may not be possible and again the only
basic principle which allows individual distinction between terminals is
the
supplementary service multiple subscriber number.
\v'1P'
.RT
.ce 1000
APPENDIX\ I
.ce 0
.ce 1000
(to Recommendation I.333)
.sp 9p
.RT
.ce 0
.ce 1000
\fBExamples of terminal selection for general purpose terminals
.sp 1P
.RT
.ce 0
.LP
I.1
    \fIScope\fR
.sp 1P
.RT
.PP
The aim of this Appendix is to describe terminal selection
functions for general purpose terminals which allow operation when multiple
terminals supporting a variety of services (including telematic services)
are in a point\(hyto\(hymultipoint configuration (S/T bus), and the full
complement of
terminal selection functions (including HLC information element) have to be
invoked for successful terminal selection.
.PP
Terminals which comply with the clauses below do not impose any
constraints on terminal configurations with respect to existing recommendations
dealing with telematic services.
.PP
Application of the terminal selection guidelines contained in this
Appendix is described in \(sc\ I.3.
.RT
.sp 1P
.LP
I.2
    \fITerminal functions\fR
.sp 9p
.RT
.PP
To meet the requirements mentioned in the scope of this Appendix, the following
functions shall be provided by terminals connected to an ISDN.
The functions are grouped into those which shall be provided as a minimum
for offering an adequate quality of service and into those which may be
implemented additionally.
.PP
\fINote\fR \ \(em\ The processing of information at the called side can be
executed in the order appropriate to a particular customer installation. The
order chosen in this Recommendation is for description and does not impose
any constraints on implementations.
.bp
.RT
.sp 2P
.LP
I.2.1\ \
\fITerminals supporting bearer services\fR
.sp 1P
.RT
.sp 1P
.LP
I.2.1.1\ \ \fIMinimum functions\fR
.sp 9p
.RT
.LP
I.2.1.1.1\ \ For outgoing calls, generation of information defining the
service and address information, i.e.\ bearer capability and called address.
.LP
I.2.1.1.2\ \ For incoming calls, analysis of whether a bearer service is
requested (not a teleservice). If a
higher layer protocol
(repesenting a specific teleservice) is requested, the terminal shall ignore
the call. This function may be provided by the simple determination of
the \fIexistence\fR of
higher layer protocol information received with the incoming call message.
.LP
I.2.1.1.3\ \ For incoming calls, analysis of the individual bearer service
requested. This function is obtained by the analysis of the bearer capability
information received with the incoming call message.
.LP
I.2.1.1.4\ \ For incoming calls, analysis of multiple subscriber number
information, if provided. A call shall only be answered if the requested
multiple subscriber number matches the identity assigned to the terminal.
.PP
Terminals which do not support the multiple subscriber number
supplementary service, shall at least detect the presence of this information.
If present, such terminals shall not answer the call.
.PP
Terminals supporting the multiple subscriber number supplementary
service must analyze this information and will only answer the call if the
received information matches the pre\(hyassigned identity or if there is
a global call.
.RT
.LP
I.2.1.1.5\ \ For incoming calls, analysis of subaddress information. A call
shall only be answered if the requested subaddress matches the one assigned
to the terminal.
.PP
Terminals which do not support the subaddressing mechanism, shall at least
detect the presence of this information. If present, such terminals
shall not answer the call.
.PP
Terminals supporting the subaddressing mechanism must analyze this
information and will only answer the call if the received information matches
the pre\(hyassigned information. Terminals with subaddress capability shall
not
reject calls on the absence of subaddress information.
.RT
.LP
I.2.1.1.6\ \ Terminals supporting more than one bearer service must apply
rules of \(sc\(sc\ I.2.1.1.1, I.2.1.1.2 and\ I.2.1.1.3 individually. The
assignment of a multiple subscriber number or a subaddress may be common
for all bearer
services.
.sp 1P
.LP
I.2.1.2\ \ \fIOptional functions\fR
.sp 9p
.RT
.LP
I.2.1.2.1\ \ Terminals supporting the multiple subscriber number supplementary
service may be pre\(hyassigned more than one number and will therefore answer
incoming calls which match one of the pre\(hyassigned identities or which
have a global identity (global call) (see Note).
.LP
I.2.1.2.2\ \ Terminals supporting the subaddressing mechanism may be pre\(hyassigned
more than one subaddress and will therefore answer incoming calls which
match one of the pre\(hyassigned subaddress or which have no subaddress
(
global
call
).
.PP
\fINote\fR \ \(em\ An incoming call is global if there is no information
contained in the call set\(hyup message to relate the call to sub\(hyset of the
terminal population based on terminal identity (information on terminal
identity is conveyed in the called party number information element). The
term \*Q
global identity
\*U is used to reflect the global relationship with
respect to terminal identity, and suitable coding methods are:
.LP
    \(em
    to omit the
called party number information element;
.LP
    \(em
     to define a specific called party number as a global number (see also
Recommendation\ Q.931).
.sp 2P
.LP
I.2.2\ \
\fITerminals supporting teleservices\fR
.sp 1P
.RT
.sp 1P
.LP
I.2.2.1\ \ \fIMinimum functions\fR
.sp 9p
.RT
.LP
I.2.2.1.1\ \ For outgoing calls, generation of information defining the
service and address information, i.e.\ bearer capability, higher layer
protocol
information specifying the requested teleservice and called address.
.bp
.LP
I.2.2.1.2\ \ For incoming calls, analysis of whether a teleservice is requested
(and not a bearer service), i.e.\ if high layer protocol information
(representing a specific teleservice) is \fInot\fR requested, the terminal
shall
ignore the call. This function may be provided by the simple determination
of the \fIexitence\fR of high layer protocol information received with
the incoming
call message. As high layer compatibility (HLC) information may not be
provided in the case of interworking with a non\(hyISDN, its absence should
not be used as a reason for rejecting the call (see \(sc\ I.2.3.1).
.LP
I.2.2.1.3\ \ For incoming calls, analysis of the individual teleservice
requested. This function is obtained by the analysis of the bearer capability
information and the high layer protocol information received with the incoming
call message.
.LP
I.2.2.1.4\ \ For incoming calls, analysis of multiple subscriber number
information. A call shall only be answered if the requested multiple subscriber
number matches the identity assigned to the terminal.
.PP
Terminals which do not support the multiple subscriber number
supplementary service, shall at least detect the presence of this information.
If present, such terminals shall not answer the call.
.PP
Terminals supporting the multiple subscriber number supplementary
service must analyze this information and will only answer the call if the
received information matches the pre\(hyassigned identity or if there is
a global call.
.RT
.LP
I.2.2.1.5\ \ For incoming calls, analysis of subaddress information. A
call shall only be answered if the requested subaddress matches the one
assigned to the
terminal.
.PP
Terminals which do not support the subaddressing mechanism shall at least
detect the presence of this information. If present, such terminals
shall not answer the call.
.PP
Terminals supporting the subaddressing mechanism must analyze this
information and will only answer the call if the received information matches
the pre\(hyassigned information. Terminals with subaddress capability shall
not
reject calls on the absence of subaddress information.
.RT
.LP
I.2.2.1.6\ \ Terminals supporting more than one teleservice must apply
rules of \(sc\(sc\ I.2.2.1.1, I.2.2.1.2 and I.2.2.1.3 individually. The
assignment of a
multiple subscriber number or a subaddress may be common for all
teleservices.
.sp 1P
.LP
I.2.2.2\ \ \fIOptional functions\fR
.sp 9p
.RT
.LP
I.2.2.2.1\ \ Terminals supporting the multiple subscriber number supplementary
service may be pre\(hyassigned more than one number and will therefore answer
incoming calls which match one of the pre\(hyassigned identities or which
have a global identity (global call).
.LP
I.2.2.2.2\ \ Terminals supporting the subaddressing mechanism may be pre\(hyassigned
more than one subaddress and will therefore answer incoming calls which
match one of the pre\(hyassigned subaddress or which have no subaddress
(global call).
.sp 2P
.LP
I.2.3
    \fITerminals interworking with dedicated networks\fR
.sp 1P
.RT
.sp 1P
.LP
I.2.3.1
    \fIGeneral\fR
.sp 9p
.RT
.PP
For calls from the ISDN to a dedicated network the interworking
function has to make provision that only calls which can be handled by the
dedicated network are forwarded.
.PP
For calls originated in the dedicated network the interworking
function may be unable to provide all elements exactly specifying the service
requested according to the rules for a call within the ISDN. For example
a call from the telephone network may be a request for telephony, for facsimile
or for modem\(hybased data transmission and is presented to the ISDN as
a request for
the 3.1\ kHz audio bearer service.
.PP
In the case of interworking with a dedicated network, appropriate
information is generated by the interworking function (progress indicator).
The presence/absence of this information should be used as a criterion
for
different treatment of a call depending on whether the call originated
within ISDN or within a dedicated network.
.RT
.sp 1P
.LP
I.2.3.1.1\ \
\fICalls from PSTN to ISDN\fR
.sp 9p
.RT
.PP
A PSTN call, supported by conventional signalling prior to arrival at an
ISDN interworking point, will belong to one of two indistinguishable call
types, i.e.\ ordinary speech of voiceband data, of which the latter includes
facsimile and modem\(hybased data. At the interworking
.bp
.PP
point the bearer   capability
\*Q3.1\ kHz audio\*U is routinely assigned to assure compatibility with
any of these call types. A \*Qprogress indicator\*U is also applied to
mark a non\(hyISDN call
source. Some PSTN customers, however, will be served from ISDN\(hycapable
exchanges and calls will be supported by common channel signalling for the
entire connection. This affords some added opportunities to make distinctions
between the call types. The extent to which this should be recommended
is for further study.
.RT
.sp 1P
.LP
I.2.3.1.2\ \ \fICalls from PSPDN to ISDN\fR
.sp 9p
.RT
.PP
(See \(sc 5.3 of this Recommendation.)
.RT
.sp 1P
.LP
I.2.3.1.3\ \ \fICalls from PSPDN to ISDN\fR
.sp 9p
.RT
.PP
(See \(sc 5.4 of this Recommendation.)
.RT
.sp 1P
.LP
I.2.3.1.4
     \fICalls from networks referred to as digital PSTNs, pre\(hyISDNs,\fR
\fIpilot ISDNs or extended IDNs to ISDNs\fR
.sp 9p
.RT
.PP
Calls providing a 64 kbit/s transfer rate transparently from one of the
above\(hymentioned networks to an ISDN terminal configuration are not yet
finally defined. The 64\ kbit/s unrestricted bearer service will be used, but
in any case there is an interworking taking place. A progress indicator is
present, indicating a non\(hyISDN call source. Specific high or low layer
functionality information cannot, however, be guaranteed. Therefore, the
only basic principle which allows distinction between individual terminals
is the
supplementary service multiple subscriber number.
.RT
.sp 1P
.LP
I.2.3.2
    \fITelephone terminals in ISDN\fR
.sp 9p
.RT
.PP
Telephone terminals have certain particular characteristics which have
to be taken into account. With these terminals, compatibility checking
will be aided by the HLC. Details are for further study. In the case of
absence of HLC information, telephone terminals may be considered in a
similar manner as terminals supporting bearer services described in \(sc\
I.2.1 above \(em\ even if
telephony is a teleservice.
.PP
Telephone terminals must interwork with the existing analogue
telephone network. For incoming calls they must therefore accept not only
the bearer capability \*Qspeech\*U, which occurs in calls within ISDN,
but also the
bearer capability \*Q3,1\ kHz audio\*U, which is the bearer capability
in case of
interworking with the analogue telephone network and which is accompanied
with call progress information indicating the interworking case.
.RT
.sp 1P
.LP
I.2.3.3
    \fIFacsimile terminals in ISDN\fR
.sp 9p
.RT
.PP
A facsimile terminal on ISDN may have the capability to support
both Group\ 2/3 mode and Group\ 4 mode (Group\ 3/Group\ 4 machine), Group\
2/3 mode only (Group\ 3 machine) or Group\ 4 mode only (Group\ 4 machine).
.PP
In order to cater for the case where calls are incoming from networks not
able to convey HLC information (e.g.\ PSTN, switched 64\ kbit/s, non\(hyISDN
networks) it must be possible for a facsimile terminal to accept calls
without the provision of an HLC information element. This may involve subscription
to the Multiple Subscriber Number (MSN) supplementary service, in order
to
substitute the missing HLC information element. Moreover, for successful
call establishment the facsimile terminal has to support the bearer service
offered by the interworking function and the mode requested by the calling
facsimile
terminal.
.PP
Similar problems may occur for facsimile calls within the ISDN, if a Group
3 machine in combination with a terminal adaptor (TA) function is
connected to the ISDN.
.PP
It is obvious that a Group 4 machine and a Group 3 machine are unable to
communicate, whatever the network configuration is, when interworking with
a dedicated network or TA. However, a Group\ 3/Group\ 4 machine is able
to
communicate to a facsimile machine connected to a dedicated network (this
is a Group\ 3 machine in the case of PSTN, and a Group\ 4 machine in the
case of
switched 64\ kbit/s, non\(hyISDN Networks) or connected to the ISDN by
means of a TA function. Appendix\ IV describes the circumstances and capabilities
of
facsimile terminals for the interworking situations identified above.
.bp
.RT
.sp 1P
.LP
I.2.3.4
    \fIData terminals in ISDN\fR
.sp 9p
.RT
.PP
Data terminals in ISDN may interwork with compatible data terminals in
a dedicated data network or in the telephone network. For outgoing calls,
the terminal has to operate as described in \(sc\ I.2.1 above and it selects
the
proper bearer capability according to the service request. For incoming
calls, a data terminal shall function as described for terminals supporting
bearer
services in \(sc\ I.2.1 above. In case of interworking with the telephone
network it has to accept calls indicating the bearer capability 3.1\ kHz
audio which is accompanied with the call progress information.
.PP
Automatic answering data terminals connected to the ISDN and
interworking with the telephone network or with the CSPDN shall support the
multiple subscriber number supplementary service, because this is the only
safeguard to avoid that a data terminal will capture each incoming telephone
call, facsimile call from the PSTN or possibly each teletex call from the
CSPDN.
.RT
.sp 1P
.LP
I.3
    \fIApplications\fR
.sp 9p
.RT
.PP
Terminals (or terminal adaptors) that follow these terminal
selection guidelines can be used on the same point\(hyto\(hymultipoint
configuration with terminals of different functionality (e.g.\ Telefax,
Teletex), but
following the same terminal selection guidelines, thereby allowing incoming
calls to be selected by the appropriate terminal. The inclusion on a
point\(hyto\(hymultipoint configuration of terminals not following these
guidelines may result in the mishandling of some calls.
.PP
Since the application of the terminal selection guidelines is not
mandatory for ISDN terminals, it is essential to ensure that the terminals
used on each multipoint interface are compatible among themselves for terminal
selection.
\v'1P'
.RT
.ce 1000
APPENDIX\ II
.ce 0
.ce 1000
(to Recommendation I.333)
.sp 9p
.RT
.ce 0
.ce 1000
\fBExamples of terminal selection in illustrative configurations\fR
.sp 1P
.RT
.ce 0
.LP
II.1
    \fIScope\fR
.sp 1P
.RT
.PP
This appendix describes arrangements indicating some methods which could
be used in terminal selection. The different terminal capabilities
described in the arrangements are for illustration only. It is the
responsibility of the terminal provider to provide terminals with capabilities
appropriate to the intended use of the terminal. It is the responsibility
of
the called party to arrange the terminals on the interface so that incoming
calls are handled according to the desires of the called party.
.PP
Each illustration indicates likely circumstances for use, and the
potential impact of using the terminals on a point\(hyto\(hymultipoint
configuration with terminals having different terminal selection functionality.
Other
terminal selection arrangements may be useful for certain circumstances.
.PP
Since the application of the terminal selection guidelines is not
mandatory for ISDN terminals, it is essential that the terminals used on
each multipoint interface are compatible among themselves for terminal
selection.
.RT
.sp 2P
.LP
II.2
    \fILimited functionality speech terminal\fR
.sp 1P
.RT
.sp 1P
.LP
II.2.1
    \fIConfiguration\fR
.sp 9p
.RT
.PP
An example of a simple terminal configuration is illustrated in
Figure\ II\(hy1/I.333. The multiple terminal configuration example consists
of up to eight voice terminals without terminal selection logic.
.bp
.RT
.LP
.rs
.sp 13P
.ad r
\fBFigure II\(hy1/I.333, p.\fR
.sp 1P
.RT
.ad b
.RT
.sp 1P
.LP
II.2.2
    \fITerminals and network capabilities\fR
.sp 9p
.RT
.PP
Calls are delivered to the interface on the basis of an ISDN
subscriber number (ISDN\(hySN). The terminals respond to the call offered
on the basis of presumed eligibility to complete the call.
.RT
.sp 1P
.LP
II.2.3
    \fIOffered call treatment\fR
.sp 9p
.RT
.PP
A terminal will respond to a set\(hyup message regardless of other
terminal selection information (e.g.\ LLC) present in the set\(hyup message.
More than one terminal may answer the offered call, but the network awards
the call to the first terminal from which it receives an answer (connect)
indication.
.RT
.sp 1P
.LP
II.2.4
    \fIApplication\fR
.sp 9p
.RT
.PP
This type of terminals is appropriate for subscribers who wish only to
receive speech calls and who are not concerned with which terminal answers
the call. The use of this type of terminal on a point\(hyto\(hymultipoint
configuration with terminals designed for anything other than speech calls
will result in the mishandling of some calls.
.RT
.sp 2P
.LP
II.3
    \fITerminal selected by\fR
\fIend point identifier (EID)\fR
\fIor subaddress\fR
.sp 1P
.RT
.sp 1P
.LP
II.3.1
    \fIConfiguration\fR
.sp 9p
.RT
.LP
    \(em
    Multiple terminals with the same subscriber number.
.LP
    \(em
     Distinction among the terminals is obtained using the EID or the subaddress
(see Figure\ II\(hy2/I.333).
.LP
.rs
.sp 13P
.ad r
\fBFigure II\(hy2/I.333, p.\fR
.sp 1P
.RT
.ad b
.RT
.LP
.bp
.sp 1P
.LP
II.3.2
    \fITerminals and network capabilities\fR
.sp 9p
.RT
.PP
The network may deliver the call using terminal identification
procedures based on the end point identifier (EID). The terminal may respond
to the set\(hyup message based on terminal identification procedures (e.g.\
use of
the EID as defined in Recommendation\ Q.932 or subaddressing).
.RT
.sp 1P
.LP
II.3.3
    \fIOffered call treatment\fR
.sp 9p
.RT
.PP
The network provides a set\(hyup message with terminal selection
information that uniquely identifies a terminal. The terminal identification
procedures based on EID or subaddressing schemes will identify a particular
terminal and this terminal will respond according to the call or service
offered.
.RT
.sp 1P
.LP
II.3.4
    \fIApplication\fR
.sp 9p
.RT
.PP
The EID is provided by the network to identify a specific terminal. The
network may make use of a
User Service Profile
together with
terminal selection data to select the EID. In other applications, particularly
those involving data terminals, each terminal may be assigned a subaddress
and would respond only to calls containing that subaddress.
.RT
.sp 2P
.LP
II.4
    \fIMultiple different terminals on a passive bus\fR
.sp 1P
.RT
.sp 1P
.LP
II.4.1
    \fIConfiguration\fR
.sp 9p
.RT
.PP
This example considers a speech terminal, a terminal adaptor for
analogue interface, and a terminal adaptor for digital interface connected
on a passive bus. The interface has been assigned three numbers that can
be used (by non\(hyISDN customers) to indicate the terminal they wish to
access. The
arrangement is shown in Figure\ II\(hy3/I.333.
.RT
.LP
.rs
.sp 26P
.ad r
\fBFigure II\(hy3/I.333, p.\fR
.sp 1P
.RT
.ad b
.RT
.LP
.bp
.sp 1P
.LP
II.4.2
    \fITerminals and network capabilities\fR
.sp 9p
.RT
.PP
In this example, the terminals are connected to an interface that has been
assigned three numbers. Any of the three numbers may be used from
another ISDN for any service supported by the subscribers' terminals. For
callers from networks that cannot indicate directly the service required
(PSTNs, CSPDNs, and PSPDNs), the first number \*Q201\(hy555\(hy1111\*U
is intended for
speech services. The second number, \*Q201\(hy555\(hy2222\*U is intended
for modem data services. The third number, \*Q201\(hy555\(hy3333\*U is
intended for access to the
terminal adaptor for digital interface.
.PP
Terminal selection based on the ISDN subscriber number, bearer
capability, and progress indicators is used to identify one (or none) of the
three terminals that is appropriate to respond to an offered call.
.RT
.sp 2P
.LP
II.4.3
    \fIOffered call treatment\fR
.sp 1P
.RT
.sp 1P
.LP
II.4.3.1
    \fISpeech terminal\fR (see Figure II\(hy4/I.333)
.sp 9p
.RT
.PP
Offered call bearer capability \(em \*QSpeech\*U:
.RT
.LP
    \ \ \ The terminal responds to the call.
.LP
    Offered call bearer capability \(em \*Q3.1 kHz audio\*U:
.LP
    1)
    Progress indicator \(em non\(hyISDN:
.LP
    i)
    Called number \(em 201\(hy555\(hy1111:
.LP
\ \ \ The terminal responds to the call
.LP
    ii)
    Other called numbers:
.LP
\ \ \ The terminal does not respond.
.LP
    2)
    No progress indicator \(em ISDN origination and transit:
.LP
    \ \ \ The terminal assumes that the call is a data call and does not respond.
.PP
Offered call with other bearer capabilities:
the terminal does not respond.
.LP
.rs
.sp 25P
.ad r
\fBFigure II\(hy4/I.333, p.\fR
.sp 1P
.RT
.ad b
.RT
.LP
.bp
.sp 1P
.LP
II.4.3.2
    \fITA for analogue interface/video display terminal\fR
.sp 9p
.RT
.PP
The terminal adaptor contains a codec that produces an analogue
signal that is connected to a modem; the modem has a V\(hySeries interface
to the Video Display Terminal (VDT). The logic is shown in Figure\ II\(hy5/I.333.
.PP
Offered call bearer capability \(em \*Q3.1 kHz audio\*U:
.RT
.LP
    1)
    Progress indicator \(em non\(hyISDN:
.LP
    i)
    Called number \(em 201\(hy555\(hy2222:
.LP
    The terminal adaptor assumes that the call is a data call and responds.
The call is connected to the video display terminal through a modem.
.LP
    ii)
    Other called number:
.LP
    The terminal adaptor does not respond.
.LP
    2)
    No progress indicator \(em ISDN origination and transit:
.LP
     The terminal adaptor responds. It assumes that, since the call originated
at an ISDN terminal, the call is a data call regardless of the called
number.
.PP
Offered call with other bearer capabilities:
the terminal adaptor does not respond.
.LP
.rs
.sp 27P
.ad r
\fBFigure II\(hy5/I.333, p.\fR
.sp 1P
.RT
.ad b
.RT
.sp 1P
.LP
II.4.3.3
    \fITA for digital interface/video display terminal\fR
.sp 9p
.RT
.PP
The terminal adaptor adapts the V\(hySeries interface to the interface
at reference point\ S of ISDN.
.PP
The adaptation includes rate adapting the 9600 bit/s rate of the
display terminal to the 64\ kbit/s rate of a B\(hychannel. The logic for the
digital terminal adaptor is shown in Figure\ II\(hy6/I.333.
.bp
.PP
For non\(hyISDN calls, it is assumed that the call is routed through an
interworking function that establishes a bearer capability of 64\ kbit/s
for the call.
.PP
Offered call bearer capability \(em \*Q64 kbit/s unrestricted\*U:
.RT
.LP
    1)
    Progress indicator \(em non\(hyISDN:
.LP
    i)
    Called number \(em 201\(hy555\(hy3333:
.LP
    The switch routes the connection through an interworking unit (e.g.
a modem). The terminal adaptor for digital interface/display terminal answers
the call.
.LP
    ii)
    Other called numbers:
.LP
    The terminal adaptor does not respond.
.LP
    2)
    No progress indicator \(em ISDN origination and transit:
.LP
     The terminal adaptor responds. It assumes that, since the call originated
at an ISDN terminal, the call is a data call regardless of the called
number.
.LP
.rs
.sp 28P
.ad r
\fBFigure II\(hy6/I.333, p.\fR
.sp 1P
.RT
.ad b
.RT
.sp 1P
.LP
II.4.4
    \fIApplication\fR
.sp 9p
.RT
.PP
This example of multiple different terminals on a passive bus
illustrates the terminal selection logic that allows the appropriate terminal,
from among a speech terminal, a terminal adaptor for analogue interface,
and a terminal adaptor for digital interface, to respond to an incoming
call. Calls from a non\(hyISDN network are selected on the basis of the
called ISDN number;
calls from an ISDN subscriber are selected on the basis of the bearer
capability. The addition to the interface of other terminals with different
functionality but using the same bearer capability would result in incorrect
terminal selection.
.bp
.RT
.ce 1000
APPENDIX\ III
.ce 0
.ce 1000
(to Recommendation I.333)
.sp 9p
.RT
.ce 0
.ce 1000
\fBExamples of terminal selection using\fR
.sp 1P
.RT
.ce 0
.ce 1000
\fBlocal terminal selection procedures\fR
.ce 0
.PP
This appendix describes the concept of a logical terminal and its application
in assisting the network to provide services to the access
through local terminal identification mechanisms.
.sp 1P
.RT
.sp 1P
.LP
III.1
    \fILogical terminals\fR
.sp 9p
.RT
.PP
There may exist up to 8 physical terminals on an S/T bus. Within
each physical terminal there may exist one or more logical terminals (as
shown in Figure\ III\(hy1/I.333). A logical terminal is considered to be
the exchange's view of the physical terminal(s) on an interface. The parameters
which are
maintained by the exchange, which describe the logical terminal
characteristics, are collectively termed to be the Logical Terminal Profile
(LTP). The
LTP
may contain such information as subscriber numbers,
bearer capabilities supported, services subscribed to, or other information
which the exchange may require to successfully offer service to the terminals
on the interface. A physical terminal can appear (to the network) to be
several logical terminals by using several unique
TEIs
(see Note), each of
which may map into a single LTP. The relationship of logical terminals
to LTPs may be one\(hyto\(hyone or many\(hyto\(hyone. The relationship
between physical terminals, logical terminals. TEIs and LTPs is illustrated
in Figure\ III\(hy2/I.333).
.PP
\fINote\fR \ \(em\ The terminal end point identifier (TEI) is part of the
D\(hychannel layer\ 2 address field [see Recommendation\ Q.921 (I.441)].
.PP
Eight logical terminals (the inner boxes, labeled LT1 to LT8) are
shown in a total of four physical terminals (the outer boxes, labeled PT1 to
PT4). Each logical terminal corresponds to one TEI. This arrangement reflects
a customer subscribing to the multiple subscriber number (MSN) supplementary
service.
.RT
.LP
.rs
.sp 23P
.ad r
\fBFigure III\(hy1/I.333, p.\fR
.sp 1P
.RT
.ad b
.RT
.LP
.bp
.LP
.rs
.sp 39P
.ad r
\fBFigure III\(hy2/I.333, p.\fR
.sp 1P
.RT
.ad b
.RT
.sp 1P
.LP
III.2
    \fIApplication\fR
.sp 9p
.RT
.PP
It is considered that the subscriber may want the exchange to
provide terminal selection functions for his terminals. A local terminal
selection procedure will accommodate this. In addition, future services
may be facilitated which could require special call treatment based on
knowledge of
the terminal(s) maintained in an LTP and identified using a local procedure.
.PP
In the context of terminating calls, when an exchange receives digits of
a subscriber number (SN) for a call to a terminal on a subscriber line,
it would search for the LTP(s) associated with the SN. It would then formulate
network\(hylayer call control messages to alert these terminals based on the
descriptions associated with the LTP. The Q.932 procedure is used to allow
association of a TEI with an LTP. The procedures used for all establishment
comply with Recommendation\ Q.931 (I.451).
.bp
.RT
.ce 1000
APPENDIX\ IV
.ce 0
.ce 1000
(to Recommendation I.333)
.sp 9p
.RT
.ce 0
.ce 1000
\fBFacsimile terminals in ISDN\fR \v'1P'
.sp 1P
.RT
.ce 0
.LP
IV.1
    \fIOutgoing calls\fR
.sp 1P
.RT
.PP
In accordance with \(sc I.2.2.1.1 a G3/G4 (Group3/Group/4) machine or a
G4 machine attempting a G4 call shall use the bearer capability according
to the capabilities of the network, which may be either \*Qcircuit\(hymode
64\ kbit/s
unrestricted 8\ kHz structured\*U (category\ I.231.1) or \*Qvirtual call\*U
(category\ I.232.1), or both of them, and provide the HLC information element
with high layer characteristics identification \*Qfacsimile group\ 4\*U.
.PP
In accordance with \(sc I.2.2.1.1 a Terminal Adaptor (TA) supporting a
G3 machine shall use the 3.1\ kHz audio bearer capability and shall provide
the HLC information element with high layer characteristics identification
\*Qfacsimile group\ 3\*U.
.PP
The actions to be taken by the calling facsimile terminal following an
unsuccessful call attempt where incompatibility has been indicated (e.g.\
cause \*Qincompatible destination\*U for calls within the ISDN, or call
rejection with a suitable cause indication in the case of interworking
with a dedicated network) require further study. The optimum condition
to achieve compatibility in a call re\(hyattempt greatly depends on the
cause indication provided to the calling
facsimile terminal and its capability to divert to the requested
characteristics for the call re\(hyattempt. For a certain type of facsimile
terminal these actions may include:
.RT
.LP
    i)
    A G3 machine shall release the call and take no further
action.
.LP
    ii)
    A G4 machine shall release the call.
.LP
    The G4 machine may initiate a call re\(hyattempt, if a
mismatch of the bearer capability has been indicated and it can match the
requested characteristics, e.g.\ in the case where the \*Qvirtual call\*U
(category\ I.232.1) bearer capability has been requested by the calling
facsimile terminal and interworking with switched 64\ kbit/s non\(hyISDN
network
takes place. Otherwise it cannot take further actions and is unable to
communicate with the called facsimile terminal.
.LP
    iii)
    A G3/G4 machine shall release the call.
.LP
     If interworking ISDN to PSTN has been indicated, or cause \*Qincompatible
destination\*U for calls within the ISDN, when the call has been
rejected, the G3/G4 machine may initiate a re\(hyattempt in the G3 mode.
It shall use the 3.1\ kHz audio bearer capability and shall provide the
HLC information element with high layer characteristics identification
\*Qfacsimile group\ 3\*U.
.LP
    If interworking ISDN, to switched 64 kbit/s non\(hyISDN
network, has been indicated when the call has been rejected, actions according
to item\ ii) may be appropriate.
.sp 1P
.LP
IV.2
    \fIIncoming calls\fR
.sp 9p
.RT
.PP
For incoming calls originated within ISDN, the facsimile terminal shall
function as described for terminals supporting teleservices in \(sc\ I.2.2.
.PP
For incoming calls from non\(hyISDN networks such as the telephone
network (PSTN), the facsimile terminal will receive the appropriate information
indicating an interworking situation (call progress information). It shall
rely on the call progress information element to accept calls which are
offered
without information specifying high layer protocols, if it matches other
elements describing the incoming call. Otherwise it shall release or ignore
the call (user options). Facsimile terminals connected to the ISDN and
interworking
.PP
with non\(hyISDN networks must support the supplementary service Multiple
Subscriber Number. This supplementary service allows to substitute the
missing information describing the call and is the only means to avoid
having a
facsimile terminal accept calls which are not appropriate to it, e.g.\
incoming call from non\(hyISDN networks such as telephone calls or data
calls.
.bp
.PP
The rules below are applicable to a certain type of facsimile
terminal. They define the criteria which should be used by the terminal to
determine whether, and in what mode it should answer the call:
.RT
.LP
    i)
     A TA supporting a G3 machine should answer the call if the following
criteria are fulfilled:
.LP
    a)
    The called party number information element, if
present, contains a number which matches the number assigned to the TA; and
.LP
    b)
    the bearer capability information element indicates
the information transfer capability \*Q3.1\ kHz audio\*U; and
.LP
    c1)
     the progress indicator information element indicates the progress description
\*Qcall is not end\(hyto\(hyend ISDN\*U (incoming call from
PSTN);and
.LP
    d1)
    the high layer compatibility information element is   not present; and
.LP
    e1)
    the called party subaddress information element is
not present;
.LP
    or (instead of c1, d1, e1)
.LP
    c2)
    the progress indicator information element is not
present (incoming call from ISDN); and
.LP
    d2)
    the high layer compatibility information element
indicates high layer characteristics identification \*Qfacsimile group\
3\*U; and
.LP
    e2)
     the called party subaddress information element, if present, contains
a number which matches the subaddress assigned to the
terminal.
.LP
    ii)
    A G3/G4 machine should answer the call in the G3 mode
(including modem and codec functions) if the following criteria are fulfilled
(incoming call from PSTN);
.LP
    a)
    The called party number information element, if
present, contains a number which matches the number assigned to the terminal;
and
.LP
    b)
    the bearer capability information element indicates
the information transfer capability \*Q3.1\ kHz audio\*U; and
.LP
    c)
     the progress indicator information element indicates the progress description
\*Qcall is not end\(hyto\(hyend ISDN\*U; and
.LP
    d)
    the high layer compatibility information element is
not present; and
.LP
    e)
    the called party subaddress information element is not present.
.LP
    iii)
     A G3/G4 machine (or a G4 machine) should answer the call in the G4 mode
(neither modem nor codec functions) if the following criteria
are fulfilled (incoming call from switched 64\ kbit/s network (non\(hyISDN);
.LP
    a)
    The called party number information element, if
present, contains a number which matches the number assigned to the terminal;
and
.LP
    b)
    the bearer capability information element indicates
the information transfer capability \*Qunrestricted digital information\*U and
transfer mode \*Qcircuit mode\*U; and
.LP
    c)
     the progress indicator information element indicates the progress description
\*Qcall is not end\(hyto\(hyend ISDN\*U; and
.LP
    d)
    the high layer compatibility information element is
not present; and
.LP
    e)
    the called party subaddress information element is not present.
.LP
    iv)
     A G3/G4 machine (or a G4 machine) should answer the call in the G4 mode
(neither modem nor codec functions) if the following criteria are fulfilled
(incoming call from ISDN);
.LP
    a)
    The called party number information element, if
present, contains a number which matches the number assigned to the terminal;
and
.LP
    b)
    the bearer capability information element indicates
the information transfer capability \*Qunrestricted digital information\*U
and a
transfer mode which is supported by the called facsimile terminal (\*Qcircuit
mode\*U or \*Qpacket mode\*U); and
.LP
    c)
    the progress indicator information element is not
present; and
.LP
    d)
    the high layer compatibility information element
indicates high layer characteristics identification \*Qfacsimile group\
4\*U; and
.LP
    e)
    the called party subaddress information element, if
present, contains a number which matches the subaddress assigned to the
terminal.
.bp
.sp 2P
.LP
Recommendation I.334
.RT
.sp 2P
.ce 1000
\fBPRINCIPLES\ RELATING\ ISDN\ NUMBERSB/FSUBADDRESSES\ TO\fR
.EF '%    Fascicle\ III.8\ \(em\ Rec.\ I.334''
.OF '''Fascicle\ III.8\ \(em\ Rec.\ I.334    %'
.ce 0
.sp 1P
.ce 1000
\fBTHE\ OSI\ REFERENCE\ MODEL\ NETWORK\ LAYER\ ADDRESSES\fR
.ce 0
.sp 1P
.ce 1000
\fI(Melbourne, 1988)\fR
.sp 9p
.RT
.ce 0
.sp 1P
.LP
1.
    \fIIntroduction\fR
.sp 1P
.RT
.PP
Recommendation X.200, covering the open systems reference model,
applies the term \*Qaddress\*U to identify service access points at each layer.
With respect to the network layer, a service access point may be identified
by an ISDN numberB/Fsubaddress. This Recommendation is provided to clarify
the
concepts and terminology which relate ISDN numbers and subaddresses to one
another and to OSI reference model network layer addresses.
.RT
.sp 1P
.LP
1.1
    \fIBasic relationships\fR
.sp 9p
.RT
.PP
The essential purpose of the network layer is to achieve routing of information
within the Open Systems Interconnection (OSI) environment. To
that
purpose it may be useful to establish a correspondence between an ISDN
address (ISDN number, possibly with subaddress) and an X.200 network layer
service
access point. However, an ISDN address may in some instances identify an\fR
end\(hysystem not conforming to the OSI model. In such cases the format
and syntax of the subaddress are available for user\(hyspecific purposes.
Section 2
summarizes the coding agreements which allow this flexibility.  (The
publication of the summary in this Recommendation is for information only
and does not indicate administrative responsibility for contents nor assure
current status of the material presented.)
.RT
.sp 1P
.LP
1.2
    \fINSAPs and ISDN addresses\fR
.sp 9p
.RT
.PP
The ISDN address (ISDN number, possibly with subaddress) may
include the OSI network layer address and thereby offer means to identify
Network Service Access Points (NSAPs). Figure\ 1/I.334 shows the three
cases,\ a), b) and\ c) below, relating an ISDN address to a particular
OSI\ NSAP address.
.PP
For completeness, references to protocol elements are included in the three
cases which follow. For circuit mode access, the callingB/Fcalled
subaddress information elements associated with the Q.931 SET\(hyUP message are
used to transmit subaddress information, while the X.25 address extension
field serves this purpose for packet mode access. For interoffice circuit
mode calls, the Q.931 subaddress information elements may be transmitted
within the access transport parameter of the Signalling System No.\ 7 (S.S.
No.\ 7) initial
address message. On packet mode internetwork calls, the X.75 address extension
field is available to carry subaddress information.
.PP
The components of the OSI NSAP address are the AFI (Authority and
Format Identifier), the IDI (Initial Domain Identifier) and possibly the
\fR DSP\ (Domain Specific Part) (see also \(sc\ 3).
.RT
.LP
    a)
    The OSI NSAP address is comprised only of an AFI IDI,
in which the IDI is semantically identical to the ISDN number. There is
no DSP. A terminal can do one of the following:
.LP
    a1)
    The entire NSAP is carried in the subaddress field;
or
.LP
    a2)
    If the conditions in \(sc\ 1.3.1 are satisfied, the
NSAP address can be inferred from the E.164 number.
.LP
     \fINote\fR \ \(em\ For circuit mode calls, the semantic content of the
AFI may be contained in the numbering and addressing plan identification
in the
Q.931 or S.S. No.\ 7 callingB/Fcalled address protocol elements. For packet
mode calls, similar information may be found in the X.25B/FX.75 protocol.
Until such time as a protocol mechanism for identifying the numbering plan
and the type of number is implemented in X.25B/FX.75, analogous to that
which exists in
Q.931B/FS.S. No.\ 7, such information may be derivable from the X.25B/FX.75
address fields which may include a numbering plan escape code. It may also
be possible for the semantic content of the AFI to be implied by network
arrangements.\fR .bp
.LP
    b)
    The OSI NSAP address is comprised of an AFI+IDI+DSP, in
which the IDI is semantically identical to the ISDN number. In this case,
the entire NSAP address is carried in the subaddressB/Faddress extension
field.
.LP
    c)
    The OSI NSAP address is comprised of an AFI+IDI+DSP, in
which the IDI is not related to the ISDN number. The entire NSAP address is
conveyed in the subaddressB/Faddress extension field.
.LP
.rs
.sp 32P
.ad r
\fBFigure 1/I.334, p.\fR
.sp 1P
.RT
.ad b
.RT
.sp 2P
.LP
1.3
    \fIEncoding of NSAP addresses\fR
.sp 1P
.RT
.sp 1P
.LP
1.3.1
    \fIUse of the AF (Address Field)\fR
.sp 9p
.RT
.PP
Under certain conditions, the NSAP address, as defined in ISO
8348 AD2, may be conveyed entirely in the AF. These conditions are:
.RT
.LP
    a)
    the NSAP address consists solely of the IDP (i.e.\ the DSP
is null);
.LP
    b)
    the AFI can be deduced from the contents of the AF
(e.g.\ with knowledge of the subnetwork to which the DTE is attached); and
.LP
    c)
    the IDI is the same as the SNPA (Subnetwork Point of
Attachment) address.
.bp
.PP
When all the above conditions are satisfied, the AF may be used to convey
the semantics of the entire NSAP address (the AFI is implied and the
contents of the AF are equivalent to the IDI). In these cases, the AEF
(Address Extension Field) may also be used (see \(sc\ 1.3.2).
.sp 1P
.LP
1.3.2
    \fIUse of the AEF (Address Extension Field)\fR
.sp 9p
.RT
.PP
When the conditions in \(sc\ 1.3.1 are not satisfied, the AEF
shall be used. The NSAP address, complete with AFI, is placed in the AEF
(type of subaddress is X.213B/FISO 8348\ AD2). In this case, the contents
of the AF are not defined by this Recommendation.
.RT
.sp 2P
.LP
1.4
    \fIDecoding of NSAP addresses\fR
.sp 1P
.RT
.sp 1P
.LP
1.4.1
    \fIAbsent AEF case\fR
.sp 9p
.RT
.PP
If the AEF is not present, then local knowledge is required by the receiving
NL (Network Layer) entity to determine whether an OSI NSAP address is to
be deduced from the content of the AF. If this local knowledge indicates
that an NSAP address is present, its abstract syntax is as follows:
.RT
.LP
    a)
    the AFI is deduced from knowledge of the subnetwork from
which the packet was received;
.LP
    b)
    the IDI is the same as the contents of the AF; and
.LP
    c)
    the DSP is absent.
.sp 1P
.LP
1.4.2
    \fIAEF case\fR
.sp 9p
.RT
.PP
If the AEF is present and the type of subaddress is X.213/ISO
8348 AD2, then the NSAP address is contained entirely within the AEF. The
abstract syntax is as follows:
.RT
.LP
    a)
    the AFI is contained within the first two digits of the
AEF;
.LP
    b)
     the IDI is the remainder of the Initial Domain Part (IDP) after any leading
and trailing padding digits are discarded; and
.LP
    c)
    the DSP, if present, constitutes the remainder of the AEF
content after any trailing padding digits are discarded.
.sp 2P
.LP
\fB2\fR     \fBMeans to specify the type of subaddress\fR
.sp 1P
.RT
.PP
Considering the three cases in which the NSAP address may be
related to the ISDN addressB/Fsubaddress, a mechanism which permits determination
of the type of subaddress present may be useful in making distinctions.
The
method of distinction is dependent upon the protocol being used.
.PP
In the case of Q.931B/FI.451, 3 bits within octet 3 of each
subaddress information element
(i.e.,\ calling and called party
subaddress)
.FS
Octets\ 1 and\ 2 of the subaddress information elements serve as information
element and length identifiers, respectively.
.FE
establish the
\*Qtype of subaddress\*U. Two existing assignments, subject to change by
responsible authorities are \*Quser\(hyspecified\*U and \*QX.213B/FISO
8348\ AD2\*U. All
other values are reserved.
.PP
The actual subaddress information is coded beginning in octet 4
with the possibility of continuing up to octet 23, i.e., the subaddress
information element has the capacity to carry a maximum of 20 octets of
subaddress information.
.RT
.LP
    \(em
     Under the X.213B/FISO 8348\ AD2 encoding of type of subaddress, the initial
two digits of the subaddress represent the AFI which permits
further distinction in subaddress encoding schemes as specified in
Figure\ 2/I.334.
.LP
    \(em
     Under the user\(hyspecified encoding of type of subaddress, the subaddress
field is encoded according to user specifications subject to a
maximum length of 20\ octets.
.PP
In the case of packet mode calls using X.25/ISO 8208, bits within
the first octet of the calling/called address extension facility parameter
field indicate the \*Qtype of address extension\*U in a similar manner.
.LP
.sp 2
.bp
.LP
.rs
.sp 34P
.ad r
\fBFigure 2/I.334, p.\fR
.sp 1P
.RT
.ad b
.RT
.sp 2P
.LP
\fB3\fR     \fBThe \fR \fBOSI NSAP address format\fR
.sp 1P
.RT
.PP
For reference purposes, a description of terms used in connection
with NSAP addresses is provided below:
.PP
The format of the NSAP address is:
.RT
.LP
.rs
.sp 6P
.ad r
\fBFigure, p.\fR
.sp 1P
.RT
.ad b
.RT
.LP
.bp
.LP
IDP
    \(em
    Initial Domain Part
. This is the part which
contains all the internationally standardized parts of the NSAP address,
i.e.\ those addresses and numbers which are controlled either by ISO or CCITT.
.LP
AFI
    \(em
    Authority and Format Identifier
. This 2\(hydigit
code indicates the authority responsible for the number following the AFI,
such as\ X.121 or\ E.164 and the format of the DSP. This is always two
digits and is allocated as per X.213/ISO 8348\ AD2.
.LP
IDI
    \(em
    Initial Domain Identifier
. This may contain,
for example, an E.164 or X.121 number. The networks which use these numbering
schemes are termed subnetwork by ISO. The overall length of the field is
determined by the maximum length of the number format being used.
.LP
DSP
    \(em
    Domain Specific Part
. In the context of an
E.164 IDI, this part contains an address which is relevant only to the
domain which has been accessed beyond the domain specified within the IDI,
such as a PBX\ extension, a LAN terminal and so on. This is a variable
length field, and is constrained by the length of the IDP, as the overall
maximum length of the OSI\ NSAP address is 20\ octets.
\v'1P'
.sp 2P
.LP
Recommendation\ I.335
.RT
.sp 2P
.sp 1P
.ce 1000
\fBISDN\ ROUTING\ PRINCIPLES\fR
.EF '%    Fascicle\ III.8\ \(em\ Rec.\ I.335''
.OF '''Fascicle\ III.8\ \(em\ Rec.\ I.335    %'
.ce 0
.sp 1P
.ce 1000
\fI(Melbourne, 1988)\fR
.sp 9p
.RT
.ce 0
.sp 1P
.LP
\fB1\fR     \fBIntroduction\fR
.sp 1P
.RT
.PP
A wide range of services is likely to be offered on ISDNs, which
will be supported by a specific set of network capabilities. From a routing
point of view, the relationship between these services and network capabilities
must therefore be considered.
.PP
The aim of this Recommendation is to lay down basic routing principles
defining the relationship between ISDN telecommunication services, as described
in the I.200\(hySeries of Recommendations, and ISDN network capabilities
as
described in the I.300\(hySeries of Recommendations. This Recommendation
addresses the relevance of these principles to the proposed routing plan
for ISDN, and
indicates what factors are involved in processing a call. ISDN routing
implications of interworking (intra\(hyISDN and with other networks) are for
further study.
.RT
.sp 2P
.LP
\fB2\fR     \fBGeneral routing principles\fR
.sp 1P
.RT
.PP
As described in Recommendation I.210, telecommunication services
are the communication capabilities offered to customers. The service concept
can therefore be considered to be time independent. A particular instance
(or use by the user) of a service is commonly referred to as a call.
.PP
Likewise, the network capabilities which support services, the ISDN
connection types, are described in Recommendation\ I.340. These connection
types are also time independent in their concept.
.PP
The
ISDN network architecture
Recommendation\ I.324 explains
how an ISDN connection type is made up of connection elements:
.RT
.LP
    \(em
    the \*Qaccess connection element\*U;
.LP
    \(em
    the \*Qnational transit connection element\*U; and
.LP
    \(em
    the \*Qinternational transit connection element\*U.
.LP
The connection elements, also time independent, are used for the
description of the different reference configurations associated with the
different connection types (see Recommendation\ I.325).
.PP
It should be noted that the user specifies only the service
required.
The network allocates the resources to set up a connection of the specific
type as necessary to support the requested service. For certain services,
additional network functions, e.g.\ additional lower layer function and/or
higher layer
functions, may be required as depicted in Figure\ 1/I.335. For examples
of such cases refer to Recommendation\ I.310.
.bp
.LP
.rs
.sp 16P
.ad r
\fBFigure 1/I.335, p.\fR
.sp 1P
.RT
.ad b
.RT
.PP
Figure 2/I.335 shows the general relationship between
telecommunication services and
ISDN connection types
. It also shows in general the association with the actual realization
of a service provision
(call) by the establishment of a connection through the selection of a route.
.PP
The relationship between a call and a connection is a \fIroute\fR . This
means that a
route\fR is the application of a particular connection to a specific call.
The connection (being an instance of a connection type) will
specify the network capabilities being used on a particular call. A route
therefore has geographical significance.
.RT
.LP
.rs
.sp 19P
.ad r
\fBFigure 2/I.335, p.\fR
.sp 1P
.RT
.ad b
.RT
.PP
In order to establish a communication an ISDN must select:
.LP
    \(em
    an appropriate connection type, i.e.\
functional
grouping
, to support the service;
.LP
    \(em
    an appropriate association between the selected functional
grouping in terms of a physical realization, i.e.\ the network allocates
the set of connection elements necessary to realize the appropriate connection
type.
.bp
.PP
The concept of connection type describes network capabilities
using the attribute technique. One of these attributes is known as
\*Qinformation transfer susceptance\*U. Some other attributes (e.g.\ \*Qconnection
control protocol\*U) describe the signalling capabilities.
.LP
    i)
    \fIInformation transfer susceptance\fR
.LP
     For each service requested by the user, the network has to provide a
connection type having a suitable value of the information transfer
susceptance attribute, involving switching and transmission capability. The
selection of an appropriate connection type is part of the routing functions.
.LP
    The relationship between the information transfer susceptance
attribute of a connection type and the transmission/switching capabilities
is detailed in Recommendation\ E.172.
.LP
    ii)
    \fISignalling capabilities\fR
.LP
    Since the telephone network will progressively evolve towards
ISDN, not all part of the network will initially have the same signalling
capabilities. Between two given exchanges in the network, the following
signalling systems for example, may be available:
.LP
    \(em
    channel associated signalling: R1, R2.
.LP
    \(em
    Signalling System No. 6
.LP
    \(em
    Signalling System No. 7: TUP
.LP
    \(em
    Signalling System No. 7: ISUP
.LP
    These different signalling systems have different signalling
capabilities. The routing functions have to take into account the signalling
capabilities of the network to ensure that the required service will be
correctly provided. It is also necessary to consider the case where the
required service can be provided, but with some restrictions.
.LP
     \fIExample\fR \ \(em\ For a telephone call between two ISDN subscribers,
TUP may be sufficient to set up a call but does not allow end\(hyto\(hyend
information
transfer and some supplementary services.
.LP
    The routing principles consider these different cases.
.PP
The ISDN routing process, which is further detailed in \(sc\ 4 is
divided into three aspects:
.LP
    1)
    matching between telecommunication services and ISDN
connection types;
.LP
    2)
    determination of parameters relevant to routing to be
conveyed and possibly processed across the signalling network;
.LP
    3)
    selection of rules for routing through the different
connection elements with respect to the reference configurations in
Recommendation\ I.325.
.LP
The \*Qrouting plan\*U itself, which is the set of rules for path
selection in the ISDN, is given in Recommendation\ E.172.
.PP
This routing plan follows the routing principles outlined in
Recommendation\ I.335 as well as other factors. Among others, the use of
connections over geostationary satellites does not call for any alterations
in the basic principles of ISDN routing.
.PP
Figure 3/I.335 shows the relationship between Recommendations relating
to routing.
.RT
.sp 2P
.LP
\fB3\fR     \fBMatching between telecommunication services and connection\fR
\fBtypes\fR
.sp 1P
.RT
.sp 1P
.LP
3.1
    \fIGeneral\fR
.sp 9p
.RT
.PP
The user requests a service not a connection type. It is the
responsibility of the network, as part of its routing functions, to allocate
a suitable connection type to support the requested service. Providing
a mapping between the ISDN services and connection types would assist the
network in its routing decisions.
.PP
Network operators will have freedom of choice in the selection of a
suitable connection type for a given service request.
.PP
For international connections, the connection type selected should,
for reasons of economy, generally be the minimum necessary to support the
service. If for reasons of congestion such a connection type is not available
the next higher capability connection type could be selected.
.bp
.RT
.LP
.rs
.sp 31P
.ad r
\fBFigure 3/I.335, p.\fR
.sp 1P
.RT
.ad b
.RT
.sp 1P
.LP
3.2
    \fIList of\fR
\fIbearer services\fR
.sp 9p
.RT
.PP
Tables 1a/I.335 and 1b.I.335 list the attribute values and
recommended provision of circuit\(hymode and packet\(hymode bearer service,
respectively, as described in Recommendations\ I.231 and\ I.232.
.RT
.sp 1P
.LP
3.3
    \fIList of\fR
\fIteleservices\fR
.sp 9p
.RT
.PP
Table 2/I.335 lists the attribute values of teleservices described in Recommendation\
I.241.
.RT
.sp 1P
.LP
3.4
    \fIList of\fR
\fIconnection types\fR
.sp 9p
.RT
.PP
Table 3/I.335 lists the recommended connection types in an ISDN as
described in Recommendation\ I.340.
.RT
.sp 1P
.LP
3.5
    \fIMapping of bearer services for ISDN connection types\fR
.sp 9p
.RT
.PP
Tables 4a/I.335, 4b/I.335 and 4c/I.335 show the mapping between
bearer services and connection types.
.PP
Note that, in certain cases, more than one connection type may be
suitable for a given bearer service. The first value would usually represent
an exact match to the already defined bearer service attribute values,
and
subsequent values would represent acceptable alternative(s).
.bp
.PP
Therefore, in determining the connection types usable for a given
bearer service the network may provide:
.RT
.LP
    a)
    a connection type which is an exact mapping between the
already defined bearer service and connection type attribute values;
.LP
    b)
    a connection type wherein the mapping between the bearer
service and the connection type attribute values differs for certain
attributes, but shall provide equivalent or superior performance to that
of\ a).
.PP
Also, permanent services might be supported on semi\(hypermanent
connections. This is for further study.
.sp 1P
.LP
3.6
    \fIMapping of teleservices to ISDN connection types\fR
.sp 9p
.RT
.PP
Teleservices are expected to be supported by the same set of
connection types, but further studies are needed on additional routing
aspects that may be required (see Table\ 5/I.335).
.RT
.sp 2P
.LP
\fB4\fR     \fBRouting process in an ISDN\fR
.sp 1P
.RT
.PP
This section describes the routing process within the ISDN using
the general model of the ISDN provided in the Recommendation\ I.324.
.PP
The routing process is the sequence of steps required to establish a connection
in response to a service request.
.PP
A diagram of how routing parameters are used in the ISDN routing
process, using the currently defined Q.760\ parameter fields is provided in
Figure\ 4/I.335.
.RT
.sp 2P
.LP
4.1
    \fIDescription\fR
.sp 1P
.RT
.sp 1P
.LP
4.1.1
    \fIUser\(hynetwork interface\fR
.sp 9p
.RT
.PP
The user places a request for a particular service. The terminal
equipment converts this request into a Q.931\ set\(hyup message. This Q.931\
set\(hyup message is presented to the user\(hynetwork interface to request
one of the
following:
.RT
.LP
    \(em
    a bearer service
.LP
    \(em
    a bearer service and supplementary service(s)
.LP
    \(em
    a teleservice
.LP
    \(em
    a teleservice and supplementary service(s)
.PP
The Q.931 request is coded to indicate the appropriate attributes of the
requested service. The information elements indicated within the Q.931
message will vary depending on the type of bearer service or teleservice
and
supplementary service(s) requested.
.sp 1P
.LP
4.1.2
    \fIOriginating local CRF\fR
.sp 9p
.RT
.PP
The originating local connection related function (CRF), e.g.\ local exchange,
processes the Q.931 service request and determines if network routing is
required. If network routing is required using S.S. No.\ 7 ISDN user part
(ISUP), the local CRF translates this request into an appopriate initial
address message (IAM) and determines the network resources needed to support
this service. The IAM contains certain attributes of a connection type
that
specifies network capabilities sufficient to support this service. During
the translation of the request the local CRF selects appropriate basic
connection components.
.RT
.sp 1P
.LP
4.1.3
    \fITransit CRF\fR
.sp 9p
.RT
.PP
The transit CRF processes the incoming IAM and generates an
appropriate outgoing IAM for the next stage of the call. The outgoing IAM
contains certain attributes that defines network capabilities required to
support this service. The transit CRF also allocates appropriate basic
connection components, e.g.\ echo cancellers, \(*m\(hyA\ law converters,
satellite
links.
.bp
.RT
.ce
\fBH.T. [T1.335]\fR
.ps 9
.vs 11
.nr VS 11
.nr PS 9
.TS
center box;
cw(312p) .
TABLE\ 1a/I.335
.T&
cw(312p) .
 {
\fBCircuit\(hymode bearer services recommended in an\fR
\fBISDN\fR
 | ua\d\u)\d
 }
.TE
.TS
center box ;
cw(24p) | cw(30p) | cw(30p) | cw(72p) | cw(36p) | cw(24p) | cw(36p) | cw(60p) .
No.    Transfer mode    Transfer rate  (kbit/s)    Transfert capability     {
Establishment of communication
 }    Structure    Communication configuration    Symetry | ub\d\u)\d
_
.T&
cw(24p) | cw(30p) | cw(30p) | lw(72p) | lw(36p) | lw(24p) | lw(36p) | lw(60p) .
1.1    circuit    64     {
unrestricted digital | uc\d\u)\d
 }    demand    8 kHz    pt\(hypt    bidirectional symmetric
.T&
cw(24p) | cw(30p) | cw(30p) | lw(72p) | lw(36p) | lw(24p) | lw(36p) | lw(60p) .
1.2    circuit    64     {
unrestricted digital | uc\d\u)\d
 }    reserved    8 kHz    pt\(hypt    bidirectional symmetric
.T&
cw(24p) | cw(30p) | cw(30p) | lw(72p) | lw(36p) | lw(24p) | lw(36p) | lw(60p) .
1.3    circuit    64     {
unrestricted digital | uc\d\u)\d
 }    permanent    8 kHz    pt\(hypt    bidirectional symmetric
_
.T&
cw(24p) | cw(30p) | cw(30p) | lw(72p) | lw(36p) | lw(24p) | lw(36p) | lw(60p) .
2.1    circuit    64    speech    demand    8 kHz    pt\(hypt    bidirectional symmetric
.T&
cw(24p) | cw(30p) | cw(30p) | lw(72p) | lw(36p) | lw(24p) | lw(36p) | lw(60p) .
2.2    circuit    64    speech    reserved    8 kHz    pt\(hypt    bidirectional symmetric
.T&
cw(24p) | cw(30p) | cw(30p) | lw(72p) | lw(36p) | lw(24p) | lw(36p) | lw(60p) .
2.3    circuit    64    speech    permanent    8 kHz    pt\(hypt    bidirectional symmetric
_
.T&
cw(24p) | cw(30p) | cw(30p) | lw(72p) | lw(36p) | lw(24p) | lw(36p) | lw(60p) .
3.1    circuit    64    3.1 kHz audio    demand    8 kHz    pt\(hypt    bidirectional symmetric
.T&
cw(24p) | cw(30p) | cw(30p) | lw(72p) | lw(36p) | lw(24p) | lw(36p) | lw(60p) .
3.2    circuit    64    3.1 kHz audio    reserved    8 kHz    pt\(hypt    bidirectional symmetric
.T&
cw(24p) | cw(30p) | cw(30p) | lw(72p) | lw(36p) | lw(24p) | lw(36p) | lw(60p) .
3.3    circuit    64    3.1 kHz audio    permanent    8 kHz    pt\(hypt    bidirectional symmetric
_
.T&
cw(24p) | cw(30p) | cw(30p) | lw(72p) | lw(36p) | lw(24p) | lw(36p) | lw(60p) .
4.1    circuit    64    alt speech/unrestricted    demand    8 kHz    pt\(hypt    bidirectional symmetric
.T&
cw(24p) | cw(30p) | cw(30p) | lw(72p) | lw(36p) | lw(24p) | lw(36p) | lw(60p) .
4.2    circuit    64    alt speech/unrestricted    reserved    8 kHz    pt\(hypt    bidirectional symmetric
.T&
cw(24p) | cw(30p) | cw(30p) | lw(72p) | lw(36p) | lw(24p) | lw(36p) | lw(60p) .
4.3    circuit    64    alt speech/unrestricted    permanent    8 kHz    pt\(hypt    bidirectional symmetric
_
.T&
cw(24p) | cw(30p) | cw(30p) | lw(72p) | lw(36p) | lw(24p) | lw(36p) | lw(60p) .
5.1    circuit    2\(mu64    unrestricted    demand    8 kHz | ud\d\u)\d    pt\(hypt    bidirectional symmetric
.T&
cw(24p) | cw(30p) | cw(30p) | lw(72p) | lw(36p) | lw(24p) | lw(36p) | lw(60p) .
5.2    circuit    2\(mu64    unrestricted    reserved    8 kHz | ud\d\u)\d    pt\(hypt    bidirectional symmetric
.T&
cw(24p) | cw(30p) | cw(30p) | lw(72p) | lw(36p) | lw(24p) | lw(36p) | lw(60p) .
5.3    circuit    2\(mu64    unrestricted    permanent    8 kHz | ud\d\u)\d    pt\(hypt    bidirectional symmetric
_
.T&
cw(24p) | cw(30p) | cw(30p) | lw(72p) | lw(36p) | lw(24p) | lw(36p) | lw(60p) .
6.1    circuit    384    unrestricted    demand    8 kHz    pt\(hypt    bidirectional symmetric
.T&
cw(24p) | cw(30p) | cw(30p) | lw(72p) | lw(36p) | lw(24p) | lw(36p) | lw(60p) .
6.2    circuit    384    unrestricted    reserved    8 kHz    pt\(hypt    bidirectional symmetric
.T&
cw(24p) | cw(30p) | cw(30p) | lw(72p) | lw(36p) | lw(24p) | lw(36p) | lw(60p) .
6.3    circuit    384    unrestricted    permanent    8 kHz    pt\(hypt    bidirectional symmetric
_
.T&
cw(24p) | cw(30p) | cw(30p) | lw(72p) | lw(36p) | lw(24p) | lw(36p) | lw(60p) .
7.1    circuit    1536    unrestricted    demand    8 kHz    pt\(hypt    bidirectional symmetric
.T&
cw(24p) | cw(30p) | cw(30p) | lw(72p) | lw(36p) | lw(24p) | lw(36p) | lw(60p) .
7.2    circuit    1536    unrestricted    reserved    8 kHz    pt\(hypt    bidirectional symmetric
.T&
cw(24p) | cw(30p) | cw(30p) | lw(72p) | lw(36p) | lw(24p) | lw(36p) | lw(60p) .
7.3    circuit    1536    unrestricted    permanent    8 kHz    pt\(hypt    bidirectional symmetric
_
.T&
cw(24p) | cw(30p) | cw(30p) | lw(72p) | lw(36p) | lw(24p) | lw(36p) | lw(60p) .
8.1    circuit    1920    unrestricted    demand    8 kHz    pt\(hypt    bidirectional symmetric
.T&
cw(24p) | cw(30p) | cw(30p) | lw(72p) | lw(36p) | lw(24p) | lw(36p) | lw(60p) .
8.2    circuit    1920    unrestricted    reserved    8 kHz    pt\(hypt    bidirectional symmetric
.T&
cw(24p) | cw(30p) | cw(30p) | lw(72p) | lw(36p) | lw(24p) | lw(36p) | lw(60p) .
8.3    circuit    1920    unrestricted    permanent    8 kHz    pt\(hypt     {
bidirectional symmetric
 }
.TE
.LP
\ua\d\u)\d
As given in Recommendation I.231.
.LP
\ub\d\u)\d
Unidirectional services are for further study.
.LP
\uc\d\u)\d
During an interim period some networks may only offer restricted digital information transfer capability (i.e. an all\(hyzero octet is not
allowed).
.LP
\ud\d\u)\d
With RDTD \*QRestricted differential time delay\*U.
.nr PS 9
.RT
.ad r
\fBTableau 1a/I.335 [T1.335], A L'ITALIENNE, p. 15\fR
.sp 1P
.RT
.ad b
.RT
.LP
.bp
.ce
\fBH.T. [T2.335]\fR
.ce
TABLE\ 1b/I.335
.ce
\fBPacket mode bearer services\fR
.ce
 | ua\d\u)\d
.ps 9
.vs 11
.nr VS 11
.nr PS 9
.TS
center box;
lw(42p) | cw(30p) | cw(24p) | cw(30p) | cw(42p) | cw(36p) | cw(24p) .
    Bearer service No.    Transfer mode    Transfer rate    Transfer capability     {
Establishment of the communication
 }    Structure
_
.T&
lw(42p) | cw(30p) | cw(24p) | cw(30p) | cw(42p) | cw(36p) | cw(24p) .
Virtual call    P1  P2    packet  packet    FS  FS    unrestricted  unrestricted    demand  permanent    SDU  SDU
_
.T&
lw(42p) | cw(30p) | cw(24p) | cw(30p) | cw(42p) | cw(36p) | cw(24p) .
User to user signalling    P3  P4    packet  packet    FS  FS    unrestricted  unrestricted    demand  permanent    SDU
.TE
.IP SDU
\ua\d\u)\d
As given in Recommendation I.232.
.IP FS
For further study.
.IP SDU
Service data unit.
.nr PS 9
.RT
.ad r
\fBTableau 1b/I.335 [T2.335], p. 16\fR
.sp 1P
.RT
.ad b
.RT
.LP
.rs
.sp 33P
.ad r
Blanc
.ad b
.RT
.LP
.bp
.ce
\fBH.T. [T3.335]\fR
.ps 9
.vs 11
.nr VS 11
.nr PS 9
.TS
center box;
cw(306p) .
TABLE\ 2/I.335
.T&
cw(306p) .
 {
\fBList of teleservices (as described in\fR
\fBRecommendation\ I.241)\fR
 }
.TE
.TS
center box;
cw(30p) | cw(36p) | cw(24p) | cw(24p) | cw(36p) | cw(36p) | cw(24p) | cw(36p) | cw(60p) .
No.    Teleservice    Transfer mode    Transfer rate (kbit/s)    Transfer capability     {
Establishment of communication
 }    Structure    Communication configuration    Symmetry
_
.T&
cw(30p) | lw(36p) | lw(24p) | cw(24p) | lw(36p) | lw(36p) | lw(24p) | lw(36p) | lw(60p) .
1.1    telephony    circuit    64    speech    demand    8 kHz    pt\(hypt    bidirectional symmetric
.T&
cw(30p) | lw(36p) | lw(24p) | cw(24p) | lw(36p) | lw(36p) | lw(24p) | lw(36p) | lw(60p) .
1.2    telephony    circuit    64    speech    reserved    8 kHz    pt\(hypt    bidirectional symmetric
.T&
cw(30p) | lw(36p) | lw(24p) | cw(24p) | lw(36p) | lw(36p) | lw(24p) | lw(36p) | lw(60p) .
1.3    telephony    circuit    64    speech    permanent    8 kHz    pt\(hypt    bidirectional symmetric
.T&
cw(30p) | lw(36p) | lw(24p) | cw(24p) | lw(36p) | lw(36p) | lw(24p) | lw(36p) | lw(60p) .
1.4    telephony    circuit    64    speech    demand    8 kHz    multipt    bidirectional symmetric
.T&
cw(30p) | lw(36p) | lw(24p) | cw(24p) | lw(36p) | lw(36p) | lw(24p) | lw(36p) | lw(60p) .
1.5    telephony    circuit    64    speech    reserved    8 kHz    multipt    bidirectional symmetric
.T&
cw(30p) | lw(36p) | lw(24p) | cw(24p) | lw(36p) | lw(36p) | lw(24p) | lw(36p) | lw(60p) .
1.6    telephony    circuit    64    speech    permanent    8 kHz    multipt    bidirectional symmetric
_
.T&
cw(30p) | lw(36p) | lw(24p) | cw(24p) | lw(36p) | lw(36p) | lw(24p) | lw(36p) | lw(60p) .
2.1    teletex    circuit    64    unrestricted    demand    8 kHz    pt\(hypt    bidirectional symmetric
_
.T&
cw(30p) | lw(36p) | lw(24p) | cw(24p) | lw(36p) | lw(36p) | lw(24p) | lw(36p) | lw(60p) .
3.1    telefax  (Group 4)    circuit    64    unrestricted    demand    8 kHz    pt\(hypt    bidirectional symmetric
_
.T&
cw(30p) | lw(36p) | lw(24p) | cw(24p) | lw(36p) | lw(36p) | lw(24p) | lw(36p) | lw(60p) .
4.1    mixed mode    circuit    64    unrestricted    demand    8 kHz    pt\(hypt    bidirectional symmetric
_
.T&
cw(30p) | lw(36p) | lw(24p) | cw(24p) | lw(36p) | lw(36p) | lw(24p) | lw(36p) | lw(60p) .
5.1    videotex | ua\d\u)\d    circuit    64    unrestricted    demand    8 kHz    pt\(hypt    bidirectional symmetric
.T&
cw(30p) | lw(36p) | lw(24p) | cw(24p) | lw(36p) | lw(36p) | lw(24p) | lw(36p) | lw(60p) .
5.2    videotex | ub\d\u)\d    circuit    64    unrestricted    demand    8 kHz    pt\(hypt    bidirectional symmetric
.T&
cw(30p) | lw(36p) | lw(24p) | cw(24p) | lw(36p) | lw(36p) | lw(24p) | lw(36p) | lw(60p) .
5.3    videotex | ub\d\u)\d    circuit    64    unrestricted    permanent    8 kHz    pt\(hypt    bidirectional symmetric
.T&
cw(30p) | lw(36p) | lw(24p) | cw(24p) | lw(36p) | lw(36p) | lw(24p) | lw(36p) | lw(60p) .
5.4    videotex | ub\d\u)\d    circuit    64    unrestricted    demand    8 kHz    multipt    bidirectional symmetric
.T&
cw(30p) | lw(36p) | lw(24p) | cw(24p) | lw(36p) | lw(36p) | lw(24p) | lw(36p) | lw(60p) .
5.5    videotex | ub\d\u)\d    circuit    64    unrestricted    permanent    8 kHz    multipt    bidirectional symmetric
.T&
cw(30p) | lw(36p) | lw(24p) | cw(24p) | lw(36p) | lw(36p) | lw(24p) | lw(36p) | lw(60p) .
5.6    videotex | ub\d\u)\d    packet    FS    unrestricted    demand    SDU    pt\(hypt    bidirectional symmetric
.T&
cw(30p) | lw(36p) | lw(24p) | cw(24p) | lw(36p) | lw(36p) | lw(24p) | lw(36p) | lw(60p) .
5.7    videotex | ub\d\u)\d    packet    FS    unrestricted    permanent    SDU    pt\(hypt    bidirectional symmetric
.T&
cw(30p) | lw(36p) | lw(24p) | cw(24p) | lw(36p) | lw(36p) | lw(24p) | lw(36p) | lw(60p) .
5.8    videotex | ub\d\u)\d    packet    FS    unrestricted    demand    SDU    multipt    bidirectional symmetric
.T&
cw(30p) | lw(36p) | lw(24p) | cw(24p) | lw(36p) | lw(36p) | lw(24p) | lw(36p) | lw(60p) .
5.9    videotex | ub\d\u)\d    packet    FS    unrestricted    permanent    SDU    multipt    bidirectional symmetric
_
.T&
cw(30p) | lw(36p) | lw(24p) | cw(24p) | lw(36p) | lw(36p) | lw(24p) | lw(36p) | lw(60p) .
6.1    telex    circuit    64    unrestricted    demand    8 kHz    pt\(hypt    bidirectional symmetric
.T&
cw(30p) | lw(36p) | lw(24p) | cw(24p) | lw(36p) | lw(36p) | lw(24p) | lw(36p) | lw(60p) .
6.2    telex    circuit    64    unrestricted    reserved    8 kHz    pt\(hypt    bidirectional symmetric
.T&
cw(30p) | lw(36p) | lw(24p) | cw(24p) | lw(36p) | lw(36p) | lw(24p) | lw(36p) | lw(60p) .
6.3    telex    circuit    64    unrestricted    permanent    8 kHz    pt\(hypt    bidirectional symmetric
.T&
cw(30p) | lw(36p) | lw(24p) | cw(24p) | lw(36p) | lw(36p) | lw(24p) | lw(36p) | lw(60p) .
6.4    telex    circuit    64    unrestricted    demand    8 kHz    multipt    bidirectional symmetric
.T&
cw(30p) | lw(36p) | lw(24p) | cw(24p) | lw(36p) | lw(36p) | lw(24p) | lw(36p) | lw(60p) .
6.5    telex    circuit    64    unrestricted    reserved    8 kHz    multipt    bidirectional symmetric
.T&
cw(30p) | lw(36p) | lw(24p) | cw(24p) | lw(36p) | lw(36p) | lw(24p) | lw(36p) | lw(60p) .
6.6    telex    circuit    64    unrestricted    permanent    8 kHz    multipt    bidirectional symmetric
.T&
cw(30p) | lw(36p) | lw(24p) | cw(24p) | lw(36p) | lw(36p) | lw(24p) | lw(36p) | lw(60p) .
6.7    telex    packet    FS    unrestricted    demand    SDU    pt\(hypt    bidirectional symmetric
.T&
cw(30p) | lw(36p) | lw(24p) | cw(24p) | lw(36p) | lw(36p) | lw(24p) | lw(36p) | lw(60p) .
6.8    telex    packet    FS    unrestricted    demand    SDU    multipt     {
bidirectional symmetric
 }
.TE
.LP
\ua\d\u)\d
Transmission between user terminal and Videotex centre.
.LP
\ub\d\u)\d
Transmission between Videotex centres and external
computers.
.LP
FS
For further study.
.LP
SDU
Service data unit.
.nr PS 9
.RT
.ad r
\fBTableau 2/I.335 [T3.335], A L'ITALIENNE, p. 17 \fR
.sp 1P
.RT
.ad b
.RT
.LP
.bp
.ce
\fBH.T. [T4.335]\fR
.ps 9
.vs 11
.nr VS 11
.nr PS 9
.TS
center box;
cw(300p) .
TABLE\ 3/I.335
.T&
cw(300p) .
 {
\fBISDN connection types (based on Table 2/I.340)\fR
 }
.TE
.TS
center box;
cw(24p) | cw(30p) | cw(30p) | cw(60p) | cw(24p) | cw(36p) | cw(36p) | cw(60p) .
Connection  type No.    Transfer mode    Transfer rate (kbit/s)    Transfer capability    Structure    Establishment of connection     {
Communication configuration | ua\d\u)\d
 }    Symmetry
_
.T&
lw(24p) | lw(30p) | cw(30p) | lw(60p) | lw(24p) | lw(36p) | lw(36p) | lw(60p) .
A.1    circuit    \ \ 64    unrestricted digital    8 kHz    switched    pt\(hypt    bidirectional symmetric
.T&
lw(24p) | lw(30p) | cw(30p) | lw(60p) | lw(24p) | lw(36p) | lw(36p) | lw(60p) .
A.2    circuit    \ \ 64    unrestricted digital    8 kHz    semi\(hypermanent    pt\(hypt    bidirectional symmetric
.T&
lw(24p) | lw(30p) | cw(30p) | lw(60p) | lw(24p) | lw(36p) | lw(36p) | lw(60p) .
A.3    circuit    \ \ 64    unrestricted digital    8 kHz    permanent    pt\(hypt    bidirectional symmetric
_
.T&
lw(24p) | lw(30p) | cw(30p) | lw(60p) | lw(24p) | lw(36p) | lw(36p) | lw(60p) .
A.4    circuit    \ \ 64    speech    8 kHz    switched    pt\(hypt    bidirectional symmetric
.T&
lw(24p) | lw(30p) | cw(30p) | lw(60p) | lw(24p) | lw(36p) | lw(36p) | lw(60p) .
A.5    circuit    \ \ 64    speech    8 kHz    semi\(hypermanent    pt\(hypt    bidirectional symmetric
.T&
lw(24p) | lw(30p) | cw(30p) | lw(60p) | lw(24p) | lw(36p) | lw(36p) | lw(60p) .
A.6    circuit    \ \ 64    speech    8 kHz    permanent    pt\(hypt    bidirectional symmetric
_
.T&
lw(24p) | lw(30p) | cw(30p) | lw(60p) | lw(24p) | lw(36p) | lw(36p) | lw(60p) .
A.7    circuit    \ \ 64    3.1 kHz audio    8 kHz    switched    pt\(hypt    bidirectional symmetric
.T&
lw(24p) | lw(30p) | cw(30p) | lw(60p) | lw(24p) | lw(36p) | lw(36p) | lw(60p) .
A.8    circuit    \ \ 64    3.1 kHz audio    8 kHz    semi\(hypermanent    pt\(hypt    bidirectional symmetric
.T&
lw(24p) | lw(30p) | cw(30p) | lw(60p) | lw(24p) | lw(36p) | lw(36p) | lw(60p) .
A.9    circuit    \ \ 64    3.1 kHz audio    8 kHz    permanent    pt\(hypt    bidirectional symmetric
_
.T&
lw(24p) | lw(30p) | cw(30p) | lw(60p) | lw(24p) | lw(36p) | lw(36p) | lw(60p) .
A.10    circuit    2\(mu64    unrestricted digital    8 kHz | ub\d\u)\d    switched    pt\(hypt    bidirectional symmetric
.T&
lw(24p) | lw(30p) | cw(30p) | lw(60p) | lw(24p) | lw(36p) | lw(36p) | lw(60p) .
A.11    circuit    2\(mu64    unrestricted digital    8 kHz | ub\d\u)\d    semi\(hypermanent    pt\(hypt    bidirectional symmetric
.T&
lw(24p) | lw(30p) | cw(30p) | lw(60p) | lw(24p) | lw(36p) | lw(36p) | lw(60p) .
A.12    circuit    2\(mu64    unrestricted digital    8 kHz | ub\d\u)\d    permanent    pt\(hypt    bidirectional symmetric
_
.T&
lw(24p) | lw(30p) | cw(30p) | lw(60p) | lw(24p) | lw(36p) | lw(36p) | lw(60p) .
B.1    packet    \ \ 64 (FS)    unrestricted digital    SDU    switched    pt\(hypt    bidirectional symmetric
.T&
lw(24p) | lw(30p) | cw(30p) | lw(60p) | lw(24p) | lw(36p) | lw(36p) | lw(60p) .
B.2    packet    \ \ 64 (FS)    unrestricted digital    SDU    semi\(hypermanent    pt\(hypt    bidirectional symmetric
_
.T&
lw(24p) | lw(30p) | cw(30p) | lw(60p) | lw(24p) | lw(36p) | lw(36p) | lw(60p) .
C.1    circuit    \ 384     {
unrestricted digital | uc\d\u)\d
 }    8 kHz    switched    pt\(hypt    bidirectional symmetric
.T&
lw(24p) | lw(30p) | cw(30p) | lw(60p) | lw(24p) | lw(36p) | lw(36p) | lw(60p) .
C.2    circuit    \ 384     {
unrestricted digital | uc\d\u)\d
 }    8 kHz    semi\(hypermanent    pt\(hypt    (unidirectionnal: FS)
.T&
lw(24p) | lw(30p) | cw(30p) | lw(60p) | lw(24p) | lw(36p) | lw(36p) | lw(60p) .
C.3    circuit    \ 384     {
unrestricted digital | uc\d\u)\d
 }    8 kHz    permanent    pt\(hypt    (unidirectionnal: FS)
_
.T&
lw(24p) | lw(30p) | cw(30p) | lw(60p) | lw(24p) | lw(36p) | lw(36p) | lw(60p) .
C.4    circuit    1536    unrestricted digital    8 kHz    switched    pt\(hypt    bidirectional symmetric
.T&
lw(24p) | lw(30p) | cw(30p) | lw(60p) | lw(24p) | lw(36p) | lw(36p) | lw(60p) .
C.5    circuit    1536    unrestricted digital    8 kHz    semi\(hypermanent    pt\(hypt    (unidirectional: FS)
.T&
lw(24p) | lw(30p) | cw(30p) | lw(60p) | lw(24p) | lw(36p) | lw(36p) | lw(60p) .
C.6    circuit    1536    unrestricted digital    8 kHz    permanent    pt\(hypt    (unidirectional: FS)
_
.T&
lw(24p) | lw(30p) | cw(30p) | lw(60p) | lw(24p) | lw(36p) | lw(36p) | lw(60p) .
C.7    circuit    1920    unrestricted digital    8 kHz    switched    pt\(hypt    bidirectional symmetric
.T&
lw(24p) | lw(30p) | cw(30p) | lw(60p) | lw(24p) | lw(36p) | lw(36p) | lw(60p) .
C.8    circuit    1920    unrestricted digital    8 kHz    semi\(hypermanent    pt\(hypt    (unidirectional: FS)
.T&
lw(24p) | lw(30p) | cw(30p) | lw(60p) | lw(24p) | lw(36p) | lw(36p) | lw(60p) .
C.9    circuit    1920    unrestricted digital    8 kHz    permanent    pt\(hypt    (unidirectional: FS)
.TE
.LP
\ua\d\u)\d
For multipoint services the necessary multipoint capabilities
have to be provided.
.LP
\ub\d\u)\d
With RDTD \*QRestricted differential time delay\*U.
.LP
\uc\d\u)\d
During an interim period some networks may only offer restricted digital information transfer capability (i.e. an all\(hyzero octet is not
allowed).
.LP
FS
For further study.
.LP
SDU
Service data unit.
.nr PS 9
.RT
.ad r
\fBTableau 3/I.335 [T4.335], A L'ITALIENNE, p. 18\fR
.sp 1P
.RT
.ad b
.RT
.LP
.bp
.ce
\fBH.T. [T5.335]\fR
.ce
TABLE\ 4a/I.335
.ce
\fBMapping of bearer services at 64 kbit/s to connection types\fR
.ps 9
.vs 11
.nr VS 11
.nr PS 9
.TS
center box;
lw(48p) | cw(14p) sw(14p) sw(14p) | cw(14p) sw(14p) sw(8p) | cw(14p) sw(14p) sw(14p) | cw(14p) sw(14p) sw(8p) | cw(24p) , ^  | c | c | c | c | c | c | c | c | c | c | c | c | ^ .
 {
Connection
types
Bearer
services
 }     {
64 kbit/s
Unrestricted digital
 }    Speech    3.1 kHz audio     {
Unrestricted digital
2 \(mu 64 kbit/s
 }    Notes
    A.1    A.2    A.3    A.4    A.5    A.6    A.7    A.8    A.9    A.10    A.11    A.12
_
.T&
lw(48p) | cw(14p) | lw(14p) | lw(14p) | lw(14p) | lw(14p) | lw(8p) | lw(14p) | lw(14p) | lw(14p) | lw(14p) | lw(14p) | lw(8p) | lw(24p) .
Unrestricted 1.1    X
.T&
lw(48p) | cw(14p) | cw(14p) | lw(14p) | lw(14p) | lw(14p) | lw(8p) | lw(14p) | lw(14p) | lw(14p) | lw(14p) | lw(14p) | lw(8p) | lw(24p) .
digital 1.2        X
.T&
lw(48p) | cw(14p) | cw(14p) | cw(14p) | lw(14p) | lw(14p) | lw(8p) | lw(14p) | lw(14p) | lw(14p) | lw(14p) | lw(14p) | lw(8p) | lw(24p) .
64 kbit/s 1.3        X    X
_
.T&
lw(48p) | cw(14p) | cw(14p) | cw(14p) | cw(14p) | lw(14p) | lw(8p) | cw(14p) | lw(14p) | lw(14p) | lw(14p) | lw(14p) | lw(8p) | cw(24p) .
. 2.1    \ua\d\u)\d            X            X                        \ub\d\u)\d
.T&
lw(48p) | cw(14p) | cw(14p) | cw(14p) | cw(14p) | cw(14p) | lw(8p) | cw(14p) | cw(14p) | lw(14p) | lw(14p) | lw(14p) | lw(8p) | cw(24p) .
Speech 2.2        \ua\d\u)\d            X            X                    \ub\d\u)\d
.T&
lw(48p) | cw(14p) | cw(14p) | cw(14p) | cw(14p) | cw(14p) | cw(8p) | cw(14p) | cw(14p) | cw(14p) | lw(14p) | lw(14p) | lw(8p) | cw(24p) .
. 2.3        \ua\d\u)\d    \ua\d\u)\d        X    X        X    X                \ub\d\u)\d
_
.T&
lw(48p) | cw(14p) | cw(14p) | cw(14p) | cw(14p) | cw(14p) | cw(8p) | cw(14p) | cw(14p) | cw(14p) | lw(14p) | lw(14p) | lw(8p) | cw(24p) .
3.1 kHz 3.1    \ua\d\u)\d                        X                        \ub\d\u)\d
.T&
lw(48p) | cw(14p) | cw(14p) | cw(14p) | cw(14p) | cw(14p) | cw(8p) | cw(14p) | cw(14p) | cw(14p) | lw(14p) | lw(14p) | lw(8p) | cw(24p) .
audio 3.2        \ua\d\u)\d                        X                    \ub\d\u)\d
.T&
lw(48p) | cw(14p) | cw(14p) | cw(14p) | cw(14p) | cw(14p) | cw(8p) | cw(14p) | cw(14p) | cw(14p) | lw(14p) | lw(14p) | lw(8p) | cw(24p) .
. 3.3        \ua\d\u)\d    \ua\d\u)\d                    X    X                \ub\d\u)\d
_
.T&
lw(48p) | cw(14p) | cw(14p) | cw(14p) | cw(14p) | cw(14p) | cw(8p) | cw(14p) | cw(14p) | cw(14p) | lw(14p) | lw(14p) | lw(8p) | cw(24p) .
Alternate 4.1    \ua\d\u)\d                                                \uc\d\u)\d
.T&
lw(48p) | cw(14p) | cw(14p) | cw(14p) | cw(14p) | cw(14p) | cw(8p) | cw(14p) | cw(14p) | cw(14p) | lw(14p) | lw(14p) | lw(8p) | cw(24p) .
speech/64 kbit/s 4.2        \ua\d\u)\d                                            \uc\d\u)\d
.T&
lw(48p) | cw(14p) | cw(14p) | cw(14p) | cw(14p) | cw(14p) | cw(8p) | cw(14p) | cw(14p) | cw(14p) | lw(14p) | lw(14p) | lw(8p) | cw(24p) .
unrestricted 4.3        \ua\d\u)\d    \ua\d\u)\d                                        \uc\d\u)\d
_
.T&
lw(48p) | cw(14p) | cw(14p) | cw(14p) | cw(14p) | cw(14p) | cw(8p) | cw(14p) | cw(14p) | cw(14p) | cw(14p) | lw(14p) | lw(8p) | cw(24p) .
Unrestricted 5.1                                        X
.T&
lw(48p) | cw(14p) | cw(14p) | cw(14p) | cw(14p) | cw(14p) | cw(8p) | cw(14p) | cw(14p) | cw(14p) | cw(14p) | cw(14p) | lw(8p) | cw(24p) .
digital 5.2                                            X
.T&
lw(48p) | cw(14p) | cw(14p) | cw(14p) | cw(14p) | cw(14p) | cw(8p) | cw(14p) | cw(14p) | cw(14p) | cw(14p) | cw(14p) | cw(8p) | cw(24p) .
2 \(mu 64 kbit/s 5.3                                            X    X
.TE
.LP
\ua\d\u)\d
May present A\(hy\(*m law conversion problems, echo control problems,
etc.
.LP
\ub\d\u)\d
Analogue transmission may also be used.
.LP
\uc\d\u)\d
For the possibility of change of service during a call, see
\(sc\ 5.2 of Recommendation\ I.340.
.LP
X
Indicates that the connection type can definitely support the service.
.LP
\fINote\ 1\fR
\ \(em\ During an interim period, some networks may only support restricted transfer capability (i.e. no all\(hyzero octet allowed).
.LP
\fINote\ 2\fR
\ \(em\ For multipoint services the necessary multipoint capabilities have to be provided.
.nr PS 9
.RT
.ad r
\fBTableau 4a/I.335 [T5.335], p. 19\fR
.sp 1P
.RT
.ad b
.RT
.LP
.rs
.sp 14P
.ad r
Blanc
.ad b
.RT
.LP
.bp
.ce
\fBH.T. [T6.335]\fR
.ce
TABLE\ 4b/I.335
.ce
\fBMapping of bearer services 64 kbit/s\fR
.ce
\fB(up to primary rate) to connection types\fR
.ps 9
.vs 11
.nr VS 11
.nr PS 9
.TS
center box;
lw(48p) | cw(18p) sw(18p) sw(18p) | cw(18p) sw(18p) sw(18p) | cw(18p) sw(18p) sw(18p) , ^  | c | c | c | c | c | c | c | c | c.
 {
Connection
types
Bearer
services
 }    384 kbit/s  unrestricted    1536 kbit/s  unrestricted    1920 kbit/s  unrestricted
    C.1    C.2    C.3    C.4    C.5    C.6    C.7    C.8    C.9
_
.T&
lw(48p) | cw(18p) | lw(18p) | lw(18p) | cw(18p) | lw(18p) | lw(18p) | cw(18p) | lw(18p) | lw(18p) .
384 kbit/s 6.1    X            \ua\d\u)\d            \ua\d\u)\d
.T&
lw(48p) | cw(18p) | cw(18p) | lw(18p) | cw(18p) | cw(18p) | lw(18p) | cw(18p) | cw(18p) | lw(18p) .
unrestricted 6.2        X            \ua\d\u)\d            \ua\d\u)\d
.T&
lw(48p) | cw(18p) | cw(18p) | cw(18p) | cw(18p) | cw(18p) | cw(18p) | cw(18p) | cw(18p) | cw(18p) .
. 6.3        X    X        \ua\d\u)\d    \ua\d\u)\d        \ua\d\u)\d    \ua\d\u)\d
_
.T&
lw(48p) | cw(18p) | cw(18p) | cw(18p) | cw(18p) | cw(18p) | cw(18p) | cw(18p) | cw(18p) | cw(18p) .
1536 kbit/s 7.1                X            \ua\d\u)\d
.T&
lw(48p) | cw(18p) | cw(18p) | cw(18p) | cw(18p) | cw(18p) | cw(18p) | cw(18p) | cw(18p) | cw(18p) .
unrestricted 7.2                    X            \ua\d\u)\d
.T&
lw(48p) | cw(18p) | cw(18p) | cw(18p) | cw(18p) | cw(18p) | cw(18p) | cw(18p) | cw(18p) | cw(18p) .
. 7.3                    X    X        \ua\d\u)\d    \ua\d\u)\d
_
.T&
lw(48p) | cw(18p) | cw(18p) | cw(18p) | cw(18p) | cw(18p) | cw(18p) | cw(18p) | cw(18p) | cw(18p) .
1920 kbit/s 8.1                            X
.T&
lw(48p) | cw(18p) | cw(18p) | cw(18p) | cw(18p) | cw(18p) | cw(18p) | cw(18p) | cw(18p) | cw(18p) .
unrestricted 8.2                                X
.T&
lw(48p) | cw(18p) | cw(18p) | cw(18p) | cw(18p) | cw(18p) | cw(18p) | cw(18p) | cw(18p) | cw(18p) .
. 8.3                                X    X
.TE
.LP
\ua\d\u)\d
An appropriate rate adaption scheme must be defined and utilized.
.LP
X
Indicates that the connection type can definitely support the
service.
.nr PS 9
.RT
.ad r
\fBTableau 4b/I.335 [T6.335], p. 20\fR
.sp 1P
.RT
.ad b
.RT
.ce
\fBH.T. [T7.335]\fR
.ce
TABLE\ 4c/I.335
.ce
\fBMapping of packet\(hymode bearer services to connection types\fR
.ps 9
.vs 11
.nr VS 11
.nr PS 9
.TS
center box;
lw(54p) | cw(18p) | cw(18p) .
 {
Connection
types
Bearer
services
 }    B.1    B.2
_
.T&
lw(54p) | cw(18p) | lw(18p) .
P.1    X
P.2        X
P.3 | ua\d\u)\d
P.4 | ua\d\u)\d
.TE
.LP
\ua\d\u)\d
The connection types for these bearer services are for further
study.
.nr PS 9
.RT
.ad r
\fBTableau 4c/I.335 [T7.335], p. 21\fR
.sp 1P
.RT
.ad b
.RT
.LP
.bp
.ce
\fBH.T. [T8.335]\fR
.ce
TABLE\ 5/I.335
.ce
\fBMapping of teleservices to ISDN connection types\fR
.ps 9
.vs 11
.nr VS 11
.nr PS 9
.TS
center box;
lw(42p) | cw(12p) sw(12p) sw(12p) | cw(12p) sw(12p) sw(12p) | cw(12p) sw(12p) sw(12p) | cw(12p) sw(12p) | cw(18p) sw(12p) | cw(24p) , ^  | c | c | c | c | c | c | c | c | c | c | c | c | c | ^ .
 {
Connection
types
Teleservices
 }    64 kbit/s  unrestricted    64 kbit/s speech    64 kbit/s  3.1 kHz audio    Packet    User signalling    Notes
    A.1    A.2    A.3    A.4    A.5    A.6    A.7    A.8    A.9    B.1    B.2    B.3    B.4
_
.T&
lw(42p) | cw(12p) | lw(12p) | lw(12p) | cw(12p) | lw(12p) | lw(12p) | cw(12p) | lw(12p) | lw(12p) | lw(12p) | lw(12p) | lw(18p) | lw(12p) | rw(24p) .
. 1.1    \ua\d\u)\d            X            X                            \ub\d\u)\d
.T&
lw(42p) | cw(12p) | cw(12p) | lw(12p) | cw(12p) | cw(12p) | lw(12p) | cw(12p) | cw(12p) | lw(12p) | lw(12p) | lw(12p) | lw(18p) | lw(12p) | rw(24p) .
. 1.2        \ua\d\u)\d            X            X                        \ub\d\u)\d
.T&
lw(42p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | lw(12p) | lw(12p) | lw(18p) | lw(12p) | lw(24p) .
Telephony 1.3        \ua\d\u)\d    \ua\d\u)\d        X    X        X    X                    \uc\d\u)\d \ub\d\u)\d
.T&
lw(42p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | lw(12p) | lw(12p) | lw(18p) | lw(12p) | lw(24p) .
. 1.4    \ua\d\u)\d            X            X                            \uc\d\u)\d \ub\d\u)\d
.T&
lw(42p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | lw(12p) | lw(12p) | lw(18p) | lw(12p) | lw(24p) .
. 1.5        \ua\d\u)\d            X            X                        \uc\d\u)\d \ub\d\u)\d
.T&
lw(42p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | lw(12p) | lw(12p) | lw(18p) | lw(12p) | lw(24p) .
. 1.6        \ua\d\u)\d    \ua\d\u)\d        X    X        X    X                    \uc\d\u)\d \ub\d\u)\d
_
.T&
lw(42p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | lw(12p) | lw(12p) | lw(18p) | lw(12p) | lw(24p) .
Teletex 2.1    X
_
.T&
lw(42p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | lw(12p) | lw(12p) | lw(18p) | lw(12p) | lw(24p) .
Facsimile 3.1    X
_
.T&
lw(42p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | lw(12p) | lw(12p) | lw(18p) | lw(12p) | lw(24p) .
Mixed mode 4.1    X
_
.T&
lw(42p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | lw(12p) | lw(12p) | lw(18p) | lw(12p) | lw(24p) .
. 5.1    X
.T&
lw(42p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | lw(12p) | lw(12p) | lw(18p) | lw(12p) | lw(24p) .
. 5.2    X
.T&
lw(42p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | lw(12p) | lw(12p) | lw(18p) | lw(12p) | lw(24p) .
. 5.3        X    X
.T&
lw(42p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | lw(12p) | lw(12p) | lw(18p) | lw(12p) | lw(24p) .
. 5.4    X                                                    \uc\d\u)\d
.T&
lw(42p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | lw(12p) | lw(12p) | lw(18p) | lw(12p) | lw(24p) .
Videotex 5.5        X    X                                            \uc\d\u)\d
.T&
lw(42p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | lw(12p) | lw(18p) | lw(12p) | lw(24p) .
. 5.6                                        X
.T&
lw(42p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | lw(18p) | lw(12p) | lw(24p) .
. 5.7                                            X            \uc\d\u)\d
.T&
lw(42p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | lw(18p) | lw(12p) | lw(24p) .
. 5.8                                        X                \uc\d\u)\d
.T&
lw(42p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | lw(18p) | lw(12p) | lw(24p) .
. 5.9                                            X            \uc\d\u)\d
_
.T&
lw(42p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | lw(18p) | lw(12p) | lw(24p) .
. 6.1    X
.T&
lw(42p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | lw(18p) | lw(12p) | lw(24p) .
. 6.2        X
.T&
lw(42p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | lw(18p) | lw(12p) | lw(24p) .
. 6.3        X    X                                            \uc\d\u)\d
.T&
lw(42p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | lw(18p) | lw(12p) | lw(24p) .
T\*'elex 6.4    X                                                    \uc\d\u)\d
.T&
lw(42p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | lw(18p) | lw(12p) | lw(24p) .
. 6.5        X                                                \uc\d\u)\d
.T&
lw(42p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | lw(18p) | lw(12p) | lw(24p) .
. 6.6        X    X
.T&
lw(42p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | lw(18p) | lw(12p) | lw(24p) .
. 6.7                                        X
.T&
lw(42p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | lw(18p) | lw(12p) | lw(24p) .
. 6.8                                        X                \uc\d\u)\d
.TE
.LP
\ua\d\u)\d
May present A\(hy\(*m law conversion problems; echo control problems,
etc.
.LP
\ub\d\u)\d
Analogue transmission may also be used.
.LP
\uc\d\u)\d
For multipoint services the necessary multipoint capabilities have to be provided.
.LP
X
Indicates that the connection type can definitely support the
service.
.nr PS 9
.RT
.ad r
\fBTableau 5/I.335 [T8.335], p. 22\fR
.sp 1P
.RT
.ad b
.RT
.LP
.rs
.sp 8P
.ad r
\fBFigure 4/I.335, p. 23\fR
.sp 1P
.RT
.ad b
.RT
.LP
.bp
.sp 1P
.LP
4.1.4
    \fITerminating local CRF\fR
.sp 9p
.RT
.PP
The terminating local CRF, e.g.\ local exchange, processes the
incoming IAM. The local CRF uses the information from within the incoming
IAM to generate an appropriate Q.931 set\(hyup message. The set\(hyup message
is then
offered to the destination terminal across the user network interface,
subject to certain local conditions and decisions.
.RT
.sp 1P
.LP
4.2
    \fIElements and parameters\fR
.sp 9p
.RT
.PP
The routing plan is a set of rules defining the process of
selecting appropriate basic connection components conforming to the connection
elements capable of supporting a given telecommunication service. These
rules are developed in Recommendation\ E.172. To be able to implement these
rules the CRFs must be capable of processing an elaborate set of parameters.
.RT
.sp 1P
.LP
4.2.1
    \fIDescription\fR
.sp 9p
.RT
.PP
This section describes the elements and parameters that may be
required for the call routing process. Different network CRFs need not
require a complete set of these parameters; however each CRF will require
a minimum set to ensure efficient and effective routing.
.RT
.LP
    a)
    \fICalling customer's subscription parameters\fR
.LP
     The local CRF may validate service requests against the customer's subscription
parameters before the outgoing route is selected.
.LP
    b)
    \fIIncoming route\fR
.LP
     Some incoming routes may require special treatment (e.g.\ not allow access
to all outgoing routes).
.LP
    c)
    \fICalled number\fR
.LP
     The called number, when provided, is used for routing. Access may be
barred to a particular network or a particular customer, under either
administrative or network management control, by analysis of the called
number.
.LP
    \fINote\fR \ \(em\ For destination network, see Table\ 7/I.335.
.LP
    d)
    \fIBasic telecommunication service request\fR
.LP
    The nature of the bearer or teleservice requested, requires
parameter analysis to determine relevant attribute values of the minimum
necessary connection type capable of supporting that service (e.g.\ information
transfer susceptance, signalling system capabilities,\ etc.).
.LP
    The parameters analyzed, for call routing, are predominantly
related to the lower layers (e.g.\ BC). The network may, however, additionally
analyze higher layer parameters (e.g.\ HLC).
.LP
    e)
    \fITransmission medium requirement (TMR)\fR
.LP
    The TMR is the encoding of the information transfer susceptance
attribute value of the minimum necessary connection type capable of supporting
the call.
.LP
     \fINote\fR \ \(em\ Relevant attributes of the minimum necessary connection
type are derived at the originating local CRF from the BC (Bearer Capability)
and supplementary service request as an intermediate step in determining
the
values of routing parameters. The information transfer susceptance is derived
from the information transfer capability and information transfer rate
fields contained in the Q.931\ BC information element.
.LP
     The encoding of the TMR may, depending on the network operator's policy,
represent a higher value of the information transfer susceptance
attribute that the minimum necessary to support the call. However, between
international and internetwork gateways, the TMR should represent the minimum
necessary (to support the requested service) and should not be modified.
The
TMR can then be used between such gateways to perform efficient routing.
This does not preclude that some gateways may need to examine additional
information [e.g.\ USI (User Service Information)].
.bp
.LP
    Table 6/I.335 identifies the relationship between some
circuit\(hymode bearer services and teleservices identified in I.230 with the
(minimum) TMR value.
.LP
    The values of TMR for other services is for further study.
.LP
.sp 1
.ce
\fBH.T. [T9.335]\fR
.ce
TABLE\ 6/I.335
.ce
\fBRelationships between the requested service and the minimum TMR
.ce
value\fR
.ps 9
.vs 11
.nr VS 11
.nr PS 9
.TS
center box;
cw(108p) | cw(36p) sw(36p) sw(36p) , ^  | c | c | c.
Requested service    TMR value
    Speech    3.1 kHz  audio    64 kbit/s  unrestricted
_
.T&
lw(48p) | lw(60p) | cw(36p) | lw(36p) | cw(36p) , ^  | l | c | l | l
^  | l | l | l | l.
Bearer services    64 kbit/s unrestricted    X    3.1 kHz audio    X
    Speech    X
_
Unable to convert table
.TE
.nr PS 9
.RT
.ad r
\fBTable 6/I.335 [T9.335], p.\fR
.sp 1P
.RT
.ad b
.RT
.LP
.sp 1
    f
)
    \fIUser Service Information (USI)\fR
.LP
     The USI is the encoding of the Q.931 BC into Q.762 ISUP. The USI parameter
may be used to regenerate attributes of the TMR required by the
routing function(s) at intermediate CRFs [see item\ e) above].
.LP
    g)
    \fISupplementary service request\fR
.LP
    Both ISDN and PSTN services may invoke various supplementary
services which may require analysis before the outgoing route is selected.
The services can be split into those supported by both the ISDN and PSTN
and those supported only by the ISDN. Within each of these two groups,
some
supplementary services may be realized as a function of the originating
local exchange (e.g.\ short code dialling) while others will require end\(hyto\(hyend
capabilities across the network (e.g.\ calling line identification and closed
user group). The provision of these latter supplementary services can influence
call routing in terms of the signalling system capability requirement.
.LP
    Therefore the supplementary service requested can influence the
value of the signalling system capability attribute of the connection type
capable of supporting that combination of basic and supplementary
service.
.LP
    h)
    \fIISUP preference indicator\fR
.LP
     This is an indicator contained within the forward call indicators parameter
field of ISUP, sent in the forward direction indicating whether or
not the ISDN user part (ISUP) is required or preferred or not required
in all parts of the network connection. This information is derived at
the originating local CRF from the network signalling capability attribute
of the minimum
necessary connection type, which is itself derived from the BC and
supplementary service request contained in the Q.931 set\(hyup message.
.bp
.LP
    i)
    \fIEnvironment of the connection\fR
.LP
    This information element contains three secondary attributes of
the requested bearer service that may influence the routing process, namely:
.LP
    1)
    the establishment of communication (demand, reserved,
permanent);
.LP
    2)
    the configuration of communication (point\(hyto\(hypoint,
multipoint, broadcast);
.LP
    3)
    symmetry (symmetric, asymmetric).
.LP
    These secondary attributes are contained in the Q.931\ BC
information element and are directly transposed by the originating local CRF
into the ISUP user service information parameter field [see item f
)
above]. The impact of the environment of the connection on TMR for future
service is for further study.
.LP
    \fINote\fR \ \(em\ Each of these three secondary attributes may invoke
special arrangements that may be necessary in order to establish, for example,
point\(hyto\(hymultipoint, or asymmetric calls.
.LP
    j)
    \fINetwork management conditions\fR
.LP
    There may be cases where network management control of routing
functions is required. (Route selection may be under control of routing
information dynamically updated by network routing processors, i.e.\ processors
monitoring network traffic flows.) For this reason CRFs may be required
to
implement capabilities for supporting this facility.
.LP
    k)
    \fITransit network selection\fR
.LP
     National networks may implement capabilities allowing requests for specific
transit network(s) to be used in the call. Impact of this on call
routing may require further study.
.LP
    l)
    \fIConnection history\fR
.LP
    In order to ensure that the number of links, the number of
satellite hops and any other network limiting functions are not exceeded
in a connection, a connection history should be available for processing
prior to
route selection. A set of relevant parameters is provided in ISUP by the
nature of connection indicators parameter field. This field is generated
at the
originating local exchange and modified at subsequent transit exchanges each
time a relevant parameter (e.g.\ number of satellite links) is affected as a
result of the transmission path chosen. Code points for other parameters,
e.g.\ number of sections with digital circuit multiplication equipment (DCME)
and A\(hy\(*m law converters, may not be required for routing purposes
since these
should be taken into account in the hypothetical digital reference connection
(HDRC) at the exchange routing data planning stage. However a signalling
capability may be necessary to provide a means of verifying that parameter
values are within the allowed limits.
.LP
     \fINote\fR \ \(em\ It is considered that the responsibility of international
operators for correctly setting up exchange routing data is of paramount
importance to ensure that signalling systems and exchange processors are not
burdened with the need for per\(hycall conveyance and examination of unnecessary
information.
.LP
    m)
    \fITime of day\fR
.LP
     Because of varying traffic distributions during a 24\ hour period, it
may be advantageous to change the call routing arrangements as a function
of the time of day.
.sp 1P
.LP
4.2.2
    \fIApplication in the\fR
\fIrouting process\fR
.sp 9p
.RT
.PP
This section deals with the application of the information elements and
parameters in the routing process identified in \(sc\ 4.2.1. The elements
and parameters are given in Table\ 7/I.335 together with their significance
with
regard to different network CRFs (nodes).
.RT
.sp 1P
.LP
4.2.2.1
    \fIOriginating local CRF\fR
.sp 9p
.RT
.PP
The originating local CRF processes the Q.931 service request and determines
if network routing is required. When routing is required, the local CRF
maps the requested service into attributes of a connection type that
specifies network capabilities sufficient to support this service. This
mapping, discussed in \(sc\ 3, defines the network resources needed to
support the service and results in the generation of an appropriate IAM.
Additionally, the local CRF allocates the appropriate basic connection
components which, as a
minimum, conform to the required connection type.
.bp
.RT
.sp 1P
.LP
4.2.2.2
    \fITransit CRF\fR
.sp 9p
.RT
.PP
The transit CRF will process an incoming IAM and will generate an appropriate
outgoing IAM.
.PP
The
incoming and outgoing IAM mesage
contains the following
parameter fields which may be used for routing purposes:
.RT
.LP
    \(em
    nature of connection indicators,
.LP
    \(em
    forward call indicators,
.LP
    \(em
    calling party's category,
.LP
    \(em
    transmission medium requirement (TMR)
,
.LP
    \(em
    called party number,
.LP
    \(em
    user service information (USI),
.LP
    \(em
    transit network selection (national use only).
.PP
The IAM message may contain other parameters whose presence may
influence the choice of signalling system capability for the call. These
parameters are:
.LP
    \(em
    call reference,
.LP
    \(em
    calling party number,
.LP
    \(em
    optional forward call indicators,
.LP
    \(em
    redirecting number,
.LP
    \(em
    CUG interlock code,
.LP
    \(em
    connection request,
.LP
    \(em
    user\(hyto\(hyuser information,
.LP
    \(em
    access transport.
.PP
The parameters listed above contain all the signalling information needed
to perform routing in the international network.
.PP
In the international network, the TMR is set to the value that
represents the minimum network capability to provide the requested service
and that value is not modified.
.RT
.sp 2P
.LP
\fB5\fR     \fBISDN routing principles applicable to network\fR
\fBinterworking\fR
.sp 1P
.RT
.PP
This section describes routing considerations in network
interworking situations (i.e.\ ISDN to/from other networks), defined in the
I.500\(hySeries of Recommendations.
.RT
.sp 1P
.LP
5.1
    \fIISDN\(hyPSTN interworking\fR
.sp 9p
.RT
.PP
Routing implications of the following ISDN\(hyPSTN interworking
scenarios are described:
.RT
.LP
    i)
    \fIISDN to PSTN\fR
.LP
    In this scenario, the call is initiated from an ISDN access and
terminated on a PSTN access.
.LP
    ii)
    \fIPSTN to ISDN\fR
.LP
    In this scenario, the call is initiated from a PSTN access and
terminated on an ISDN access.
.PP
These scenarios do not apply to network interworking situations
wherein a transit network other than an ISDN or PSTN is involved.
.PP
The ISDN bearer capabilities that are compatible with the capabilities
of the PSTN are identified in Recommendation\ I.530. In the general case,
an
ISDN\(hyoriginated call incompatible with PSTN capabilities is cleared with an
appropriate message.
.RT
.sp 1P
.LP
5.1.1
    \fIISDN to PSTN direction\fR
.sp 9p
.RT
.PP
In the ISDN to PSTN direction, a call originating from an ISDN
access encounters ISDN to PSTN interworking in the following cases:
.RT
.LP
    i)
    the call destination is on a PSTN access;
.LP
    ii)
    interworking with a non\(hyISUP signalling system is
encountered.
.bp
.ce
\fBH.T. [T10.335]\fR
.ce
TABLE\ 7/I.335
.ce
\fBElements and parameters in routing process\fR
.ce
(Note\ 1)
.ps 9
.vs 11
.nr VS 11
.nr PS 9
.TS
center box;
cw(108p) | cw(30p) sw(30p) sw(30p) sw(30p) , ^  | c | c | c | c.
 {
Generic list of information which may be
required for call routing
 }     {
Information to be taken into account
for routing purposes at:
 }
    Originating local exchange    National transit exchange    International exchange (ISC)    Terminating local exchange
_
.T&
lw(108p) | cw(30p) | lw(30p) | lw(30p) | lw(30p) .
 {
a)
Calling customer's subscription parameters
 }    X
_
.T&
lw(108p) | cw(30p) | cw(30p) | cw(30p) | lw(30p) .
b) Incoming route         X    X
_
.T&
lw(108p) | cw(30p) | cw(30p) | cw(30p) | cw(30p) .
 {
c)
Called number (including NPI/TON information, if present)
 }    X    X    X    X
_
.T&
lw(108p) | cw(30p) | cw(30p) | cw(30p) | cw(30p) .
Destination network    X    X    X
_
.T&
lw(108p) | cw(30p) | cw(30p) | cw(30p) | cw(30p) .
 {
d)
Basic service request \(em bearer capability (BC)
 }    X
_
.T&
lw(108p) | cw(30p) | cw(30p) | cw(30p) | cw(30p) .
 {
e)
Transmission medium requirement (TMR)
 }    Generated    X    X (Note 2)    Terminated
_
.T&
lw(108p) | cw(30p) | cw(30p) | cw(30p) | cw(30p) .
 {
f)
User service information (USI)
 }    Generated    X    X (Note 2)
_
.T&
lw(108p) | cw(30p) | cw(30p) | cw(30p) | cw(30p) .
 {
g)
Supplementary service request
 }    X (Note 3)
_
.T&
lw(108p) | cw(30p) | cw(30p) | cw(30p) | cw(30p) .
h) ISUP preference indicator    Generated    X    X    Terminated
_
.T&
lw(108p) | cw(30p) | cw(30p) | cw(30p) | cw(30p) .
 {
i)
Environment of the connection
 }    X
_
.T&
lw(108p) | cw(30p) | cw(30p) | cw(30p) | cw(30p) .
 {
j)
Network management conditions
 }    X    X    X
_
.T&
lw(108p) | cw(30p) | cw(30p) | cw(30p) | cw(30p) .
k) Transit network selection    X    X
_
.T&
lw(108p) | cw(30p) | cw(30p) | cw(30p) | cw(30p) .
l) Connection history    Generated    X    X    Terminated
_
.T&
lw(108p) | cw(30p) | cw(30p) | cw(30p) | cw(30p) .
m) Time of day    X    X    X
.TE
.LP
\fINote\ 1\fR
\ \(em\ This table identifies the elements and parameters normally used to route calls. The use of other elements and parameters is not precluded for
special circumstances at any routing stage.
.LP
\fINote\ 2\fR
\ \(em\ The USI parameter field containing the BC information element may be processed if necessary to regenerate the required TMR value capable of
supporting the requested service. For calls where BD\ =\ speech or 3.1\ kHz
audio, between A and \(*m\(hylaw networks the BC would be modified (by the \(*m\(hylaw
international gateway) accordingly.
.LP
\fINote\ 3\fR
\ \(em\ The supplementary service request may influence the value of the
ISUP preference indicator.
.nr PS 9
.RT
.ad r
\fBTableau 7/I.335 [T10.335], p. 25\fR
.sp 1P
.RT
.ad b
.RT
.LP
.rs
.sp 3P
.ad r
Blanc
.ad b
.RT
.LP
.bp
.PP
On ISDN to PSTN calls, the call is routed as in an ISDN up to the interworking
point. The routing decision is performed at the interworking
point. This decision is generally based on information available in the ISUP
initial address message. If the interworking point is a transit CRF (national
or international) where interworking with a non\(hyISUP signalling system
is
encountered, signalling interworking (ISUP to/from non\(hyISUP) is also
performed. If the call can proceed to the PSTN, call establishment continues
using normal routing procedures within the PSTN from the interworking point
onwards.
.PP
On ISDN to PSTN calls, progress indications are returned via S.S.
No.\ 7 ISUP and the procedures of Q.931 to the ISDN origination as soon as
interworking with the PSTN is encountered.
.RT
.sp 1P
.LP
5.1.2
    \fIPSTN to ISDN direction\fR
.sp 9p
.RT
.PP
In the PSTN to ISDN direction, a call encounters PSTN to ISDN
interworking in the following cases:
.RT
.LP
    i)
    the call destination is on an ISDN access;
.LP
    ii)
    interworking with an ISUP signalling system is
encountered.
.PP
In the general case, a call originating from a PSTN access is
assumed by the network to be either a voice call or modem\(hyderived voice\(hyband
data call; these two call types are indistinguishable. On PSTN to ISDN
calls, the call is routed using normal PSTN routing procedures up to the
interworking point. At the interworking point the call is routed in the
ISDN and offered to the destination as a \*Q3.1\ kHz audio\*U call accompanied
by an appropriate Q.931 progress indication.
.PP
For some cases, the selection of 3.1\ kHz audio may be inappropriate. For
example, for PSTN\(hyISDN data interworking using the 64\ kbit/s bearer
service, refer to Recommendation\ I.231. Various selection mechanisms are
contained in Recommendation\ I.515. The routing impacts are for further study.
.PP
If the interworking point is a transit CRF (national or international)
where interworking with an ISUP signalling system is encountered, signalling
interworking (non\(hyISUP to/from ISUP) is performed at this interworking
point.
.RT
.sp 1P
.LP
5.2
    \fIISDN\(hyPSPDN interworking\fR
.sp 9p
.RT
.PP
Routing implications of ISDN\(hyPSPDN interworking are for further
study.
.RT
.sp 1P
.LP
5.3
    \fIISDN\(hyCSPDN interworking\fR
.sp 9p
.RT
.PP
Routing implications of ISDN\(hyCSPDN interworking are for further
study.
.RT
.sp 1P
.LP
5.4
    \fIISDN\(hyISDN interworking over concatenated networks\fR
.sp 9p
.RT
.PP
Network concatenation occurs when an existing network (e.g.\ PSTN, CSPDN,
PSPDN) provides a connection between the originating and terminating
ISDNs. The routing implications of network concatenation scenarios are for
further study.
.RT
.LP
.rs
.sp 10P
.ad r
Blanc
.ad b
.RT
.LP
.bp
.LP
\fBMONTAGE: PAGE 110 = PAGE BLANCHE\fR
.sp 1P
.RT
.LP
.bp